Opinion Wanted: XML Component

[Guest_imported]

I need opinions on how to build the following component...

The file server holds 5 XML files. These 5 XML files (yes, only five) contain all of the data for a rather large enterprise-level application. I need to create a single object to be used in both a web application and a Windows application. Both of these applications will need to insert, update, select, and delete XML nodes and attributes from these same files at the same time.

Obviously, my concerns are file locking and massive memory consumption using multiple instances of this object. Also, the data in each of these files cannot be out of sync at any moment.

Unfortunately, I cannot deviate from these requirements. I'd like some advice on creating the object and using these five files. Any and all ideas are welcome.

Thanx,
Ryan

 

[chiph]

Why are you using XML files? Why not use a database, which already has multi-user capabilities (ACID transaction control, hot-backups, etc)?

Chip H.

 

[Guest_imported]

The files are already there and the client will not allow them to be pulled into a database. It's a requirement that I have to meet.

R/S
Ryan

 

[chiph]

Yuck.

Well, it's not going to be pretty.
In order to prevent multiple processes/threads from attempting to write to the XML files at the same time (causing data corruption), you'll need to have a single process act as a gatekeeper. All writing to these files must go through the gatekeeper.

If the customer can tolerate an occasional reader getting a partial update (the reader reads while an update is in progress, getting partially updated data) then you can allow multiple readers. Otherwise, you'll need to integrate reading into your gatekeeper too, so that reads while an update is in progress are not allowed.

I wouldn't write a gatekeeper as a class (to be included in various projects), as you'll then have problems with your Web users doing an update while your Windows users are doing reads (and vice-versa). Best to have it as a standalone process (i.e. Windows Service) that clients can call via a network protocol.

Using Web services might be good as your protocol (they're hip, and they give you a third set of potential clients), but they're not tremendously fast. For performance you'll want to go low-level with socket communications.

Chip H.