Relationship among Data class, RAF instance(s), and clients

[Zafer Abu saeed]

Hello everybody,

I'm to implement the Data class, and I have the following options regarding the realtionship
between Data class, RAF instance(s), and clients:

- Singleton Data/static RAF to server all clients
- Singleton Data/new RAF object for each call to a data-access-method (read, update,..)
- One Data instance+RAF object for each client

I think the second way (new RAF for every data-access call) is superfluous, but what about the
first and the third options?

Can someone please elaborate on which of these methods is better and why..

Thanks in advance.

[Andrew Monkhouse]

Hi Zafer,

I am going to break your options differently before discussing them:

Having a Singleton Data class or not.

Before implementing the Singleton pattern, you should ask yourself whether it is possible that at any time in the future you might conceivably want to have more than one instance of the class. In this case, is there any chance that someone might want to have more than one instance of the Data class in the future?

According to the current specifications, the answer might be no. However requirements change over time, and it is quite possible that at some point in the future there might be a need for the program to deal with additional data tables - as one example, they might want a table containing customer details (name, address, customer ids). There is nothing in the interface you have been given that is specific to the type of data you are accessing - that is, the Data class could be used for accessing a Customer table as well.

But here is the problem - if you have decided at this early stage that Data class is going to be a Singleton, then you cannot have access both tables simultaneously. You are going to have the unpleasant choice of re-writting the Data class, or duplicating the Data class, or trying to code around it (which would end up with some potentially horrible code).

Having a Data class instance per connected client.

The main advantages of this lie in the fact that (1) your Data class has less to worry about as far as thread safety is concerned, and (2) the instance of the Data class itself can be used as an identifier.

Note that thread safety is still an issue, so you cannot rely on the first point too much. This is especially true when dealing with locking records - you must take care to ensure that this section of your code is thread safe. However this in itself could cause problems - you now have one part of your class that must be thread safe, and another that is not so strict. This could cause confusion for a junior programmer - make sure you add implementation documentation around the bits that are required to be thread safe.

The second issue only really affects those who (a) have lock methods without cookies and who are calling the lock methods from the client application using RMI, or (b) are using a WeakHashMap to clear stale locks (which we wont get into here). If you have a lock cookie, then you already have a method of identifying who owns the lock. If you are calling lock only from within a server side method or from a Sockets solution then you could use the thread as the lock owner identifier. But when using RMI to call the lock method without cookies, you need something else to identify the client - and having an instance of the Data class suits this admirably.

Having a single or multiple RAF instances

At the end of the day, there is only one physical file on disk.

Some operating systems allow unrestricted access to the file (although this is rare), some only allow access to different disk blocks (at present, my Windows 2000 computer has a disk block size of 4096 bytes) within a file, and some only allow a single file pointer per physical file (although I suspect that Java might abstract that so that it appears that there are multiple file pointers per file - but I have not delved into this at all). So having multiple RAFs open might give you a slight performance gain, but there are no guarantees.

[Side note: large database systems (such as Oracle) get around this by spreading tables over multiple physical files (preferrably on multiple hard drives), so no matter what the underlying OS does, the database can always give best concurrency.]

However there is another issue to be aware of: some operating systems (mainly the true multi-user systems) limit the number of open file pointers per process (I think Solaris has a limit of 32 file pointers per process). So if you allow every client to get their own file pointer, then you might be limited to only 32 clients . The best way around this would be to have a pool of file pointers - but this means you are going to have to delve into pool management.

An alternative to consider might be whether a cache of data might work better than multiple RAFs. You would have to consider expected usage patterns for the file before you could consider this. And this is a separate topic in it's own right .

This has just been a high level overview of some of the issues involved. It may have answered your question, and it may have raised new questions . There is no one right answer (although you may have gathered that there are some that I consider wrong). You will have to weigh up the options yourself and choose for yourself what works for you (and what you are willing to put in your choices document and pottentially describe in your written exam).

Regards, Andrew

[Zafer Abu saeed]

Great!
I love it when someone answers my questions.
And I love it more when someone can understand the issues that I face from my confused questions and answer them for me.

Thank you very much Andrew.

For me, I will use Single Data instance (but not singleton class) and single RAF instance. This will be easier for me and for the junior programmer!

[Zafer Abu saeed]

One final thought..

I was searching for all magic-cookie-related threads, and read them all, found that many guys are hard-coding the value of the magic cookie in the Data class source.
Therefore it will not be possible to use the same Data class for interpreting other database files without touching the source code first (to change the hard-coded magic cookie value).
If this is the case (source code will be modified anyway) then I don't see another reason not to make the Data class singleton.

(+) I think it will be better to set the magic value in the properties file instead of hard-coding it in the source code.

Thoughts?
[ November 23, 2005: Message edited by: Zafer Abu saeed ]

[Peter Joosten]

Originally posted by Andrew Monkhouse:

Having a single or multiple RAF instances

At the end of the day, there is only one physical file on disk.

Some operating systems ...

Interesting ... So to be on the safe side I should implement a single RAF
( / single filepointer). Consequence: I can have multiple concurrent threads, but they can write to or read from the RAF, only 1 at a time. I cannot have simultanious reads of the same record, or writes to different records (of course). But then, what's the point of locking a record, I might
just as well lock the whole table :-) Food for thought! It's late, maybe my mind is not clear at the moment. I'll better go to bed and rethink this tomorrow. Comments are very welcome!
[ November 23, 2005: Message edited by: Peter Joosten ]

[Andrew Monkhouse]

Hi Zafer,

I was searching for all magic-cookie-related threads, and read them all, found that many guys are hard-coding the value of the magic cookie in the Data class source.
Therefore it will not be possible to use the same Data class for interpreting other database files without touching the source code first (to change the hard-coded magic cookie value).
If this is the case (source code will be modified anyway) then I don't see another reason not to make the Data class singleton.

The way I see it is that the magic cookie confirms that the file is in the correct format to be read by the Data class, regardless of what the file contains. So the meta-data will be in the same format and the schema will be in the same format for a given magic cookie.

That is, the magic cookie for the following meta-data and schema:

4 byte numeric, magic cookie value. Identifies this as a data file 
2 byte numeric, number of fields in each record 
 
Schema description section. 
Repeated for each field in a record: 
1 byte numeric, length in bytes of field name 
n bytes (defined by previous entry), field name 
1 byte numeric, field length in bytes 
end of repeating block

Will be a different magic cookie than the one used for the following meta-data and schema:

Start of file 
4 byte numeric, magic cookie value. Identifies this as a data file 
4 byte numeric, total overall length in bytes of each record 
2 byte numeric, number of fields in each record 
 
Schema description section. 
Repeated for each field in a record: 
2 byte numeric, length in bytes of field name 
n bytes (defined by previous entry), field name 
2 byte numeric, field length in bytes 
end of repeating block

If I write my Data class such that it checks the magic cookie for the first example, and expects the meta-data and schema for that first example, then it will be able to read any file that has the same magic cookie, meta-data and schema. But as you can easily see, without the check on the magic cookie, the Data class would quickly fail when trying to read the second file format - the field sizes are different, and some fields are different.

However all that I have confirmed with the magic cookie is that the meta-data and schema are correct. The actual contents of the file and the column names etc., are irrelevant to the Data class - it is only interested in dealing with data (maybe that's why it is called Data class ) - it is not specific to the type of data held within the file.

Does this make sense?

Regards, Andrew

P.S. Yes, both these examples were taken from real assignments, and there are likely to be more examples of how the meta-data and schema are defined as well

[Andrew Monkhouse]

Hi Peter,

But then, what's the point of locking a record, I might
just as well lock the whole table :-)

Locking the whole table will give you very low concurrency. Normally a booking request would follow at least the following steps:

lock the record

retrieve the latest copy of the record

check that it is still available

modify the record

unlock the record

If you lock the whole table then only one client can be performing all those steps at any given time, however disk access is only a small part of all that time - the reading of the bytes from the disk, and the writing of bytes back to the disk. All the other work, including converting the bytes into Strings, validating whether the record is still available etc., can be done in non-synchronized blocks. Some of that work can be done on different JVMs on different computers - for example the validation that the record is still available does not have to be done on the server.

This also brings up the issue of validating whether the record is still available. As mentioned, the Data class is not specific to the type of data held in the file - it could be any type of data. So you don't really want to be performing your availability check on a specific field within the Data class, otherwise you will be limiting the Data class to a particular type of Data. Even performing a validation where only one field may change between the current data and the data to be written is putting restrictions on the Data class that are not implied in the comments for the update method; and could severly limit other potential users of the Data class.

Regards, Andrew