Design issues

[Kevin Mc Cusker]

Hi all,
My database object (one per client) has some static lists holding records etc. When (and how) should I persist any updates to disk? At the minute I'm doing it with every option thats changing data but it means lots of I\O, but on the other hand is safer in case of the server crashing and changes getting lost for example (could this be a reason for keeping with my design?).

Also,
My database constructor populates the static lists, by reading the file:

class Database
{
static List records = new ArrayList();
public Database
{
try{
//read file, and add to records
}
catch{}
}
}

Now, take this scenario:

Client A connects, creates first database instance and static list gets populated, Client A then updates the Static list.
At the same time client B connects, before Client A persists changes to file.
Because client B created its database object before Client A updated the file the static list is repopulated with old data.

Basically i need suggestions as to how, after initial db object creation, I can stop subsequent database objects re-populating my static list. I dont see how i can take the try\catch clause out of the constructor.

Thanks.

[Roy Mallard]

Sounds like you need to lock the record list against concurrent access during startup. The record list will obviously only need to be populated once (when your server starts up and you read the .db file)

[Kevin Mc Cusker]

I think a static method called from a static block in my constructor would stop unwanted data re-initialization.

But does anyone think its good idea to immediately persist changes to the .db file? if not, how else could i implement it? ie, when would the updated records get wrote to file.

[Adam Nace]

Originally posted by Kevin Mc Cusker:
But does anyone think its good idea to immediately persist changes to the .db file? if not, how else could i implement it? ie, when would the updated records get wrote to file.

This is a question of trade-offs, and everybody must consider this individually. The trade-off is basically this:

If you force IO operations too often, and there are a lot of clients, then the server could start to become unresponsive.

BUT

If you don't force IO operations often enough, then when the application crashes, you lose more data.


SO

What is more acceptable? Is it better to lose data, or to have a sluggish server?

How many clients will be on-line at a time ? -> This effects whether the server will actually become sluggish.

What will be the consequences of lost data? How difficult will it be to get the data back? Will you be able to identify WHICH data was lost? Will you have contact information for the customer if data is lost? Will the customer base be sufficiently small enough to identify which customer's data was lost? Will it really matter if a little bit of data is lost?

You can probably tell by looking at the questions I have written that I'm leaning towards saving the data after every modification, but I'd be interested to hear other people's opinions, and also I'd be interested in what other concerns people may have considered.

- Adam

[Adam Nace]

Originally posted by Kevin Mc Cusker:
Hi all,
My database object (one per client) has some static lists holding records etc. When (and how) should I persist any updates to disk? At the minute I'm doing it with every option thats changing data but it means lots of I\O, but on the other hand is safer in case of the server crashing and changes getting lost for example (could this be a reason for keeping with my design?).

Also,
My database constructor populates the static lists, by reading the file:

class Database
{
static List records = new ArrayList();
public Database
{
try{
//read file, and add to records
}
catch{}
}
}

Now, take this scenario:

Client A connects, creates first database instance and static list gets populated, Client A then updates the Static list.
At the same time client B connects, before Client A persists changes to file.
Because client B created its database object before Client A updated the file the static list is repopulated with old data.

Basically i need suggestions as to how, after initial db object creation, I can stop subsequent database objects re-populating my static list. I dont see how i can take the try\catch clause out of the constructor.

Thanks.

Personally, I would separate the record lists from the Database object. I would put them in a separate, singleton object. This way, you initialization exactly once always. By using the singleton design pattern, which has been documented to the Nth degree, you can ensure that your data is always safely loaded exactly once, before ever being used by ANY other objects. Just by following the pattern. Be sure, though, that the reference you use to get familiar with the Singleton pattern is intended for multi-threaded use (i.e. if you use lazy initialization, synchronize the getInstance method).

- Adam

[Kevin Mc Cusker]

Thanks Adam,
Ive looked into it and agree, a singleton oblect is the way to go. A nice clean implementation.
Im also going with the update file on every change.
My head is much clearer now, Thank You!