NX: What is the point of multiple instances?

[Jim Thompson]

Great site.
What is the point of multiple client instances of the Data or DataSchema class, or however the server-side is set-up to handle client requests, if one synch's off a static RandomAccessFile pointer? All the instances have to wait for the one pointer, so why not make everything a singleton?
Thanks

[Philippe Maquet]

Hi Jim,
Welcome to JavaRanch and this forum !

Great site.

Indeed !

What is the point of multiple client instances of the Data or DataSchema class, or however the server-side is set-up to handle client requests, if one synch's off a static RandomAccessFile pointer? All the instances have to wait for the one pointer, so why not make everything a singleton?

You are right in the case there is no cache and you use a "basic" RAF on which you synchronize all db accesses.
But the possible design choices are so various in the data area :

Many people here implement a cache and most of them use a full-caching scheme. But others implement partial dynamic caching, in which case some client may read a record from the cache while another reads a record from the file itself.

Some people implementing full caching use the records as monitors for synchronization, allowing more concurrency.

Some people use a FileChannel got from the RAF. FileChannels allow concurrent access to some point.

Very few people (I could say "I" ) use a special synchronization class which allows concurrent reads / exclusive writes.

Those were just examples of what can be done.
Regards,
Phil.
[ January 01, 2004: Message edited by: Philippe Maquet ]

[Javini Javono]

Hi Phil,
Thanks for your response. This explains why there are so many different
explanations given in different threads of this group.
May I interject my question into this thread? I do so because it seems
quite relevant. I'm not sure how you all create links to other, past
threads, but my thread is called "Locking and Unlocking and Sun's Must Conditions"
started on January 1, 2004.
In short: if plan to use singletons and synchronized methods in my business logic
class (i.e., such as a book() method), and if this is considered a legitimate
solution (no caching involved), then I don't see much reason for the lock(),
unlock(), and isLocked() methods of the Data class which "must" be implemented.
Thanks,
Javini Javono

[Philippe Maquet]

Hi Javini,

I'm not sure how you all create links to other, past
threads, but my thread is called "Locking and Unlocking and Sun's Must Conditions"
started on January 1, 2004.

Simple : use the URL UBB code. Look here for a list of all UBB codes.
I had read your other thread before you posted this one.
I didn't post anything there because I fully agreed with what Andrew wrote (and still after your own reply). BTW, I can share with you a bit of my personal statistics about this forum : statistically, Andrew is wrong only 1 out of 1000 times, but only just ! So when Andrew writes to you and you *think* he is wrong, read him again - even ten times if needed - till the light comes in.
Regards,
Phil.

[Peter Yunguang Qiu]

Many people here implement a cache and most of them use a full-caching scheme. But others implement partial dynamic caching, in which case some client may read a record from the cache while another reads a record from the file itself.

Q1:
"implement a cache" means store records from db file to memory, using vector or ArraList or String[] array, or what ever, right? "full-caching" means store all records of db file to the memory using Vector or ArraList or String[] array, or what ever, right?
Q2:
For implementing caching, when to store data back to db file?
Q3:
Do we have to think of the size of the memory? The record number is long. Does it imply the db file might be huge? If it does, implements full-cachintg might loose marks. Suppose record mumber is int, should we think of the size of the memory?
Peter

[Javini Javono]

Hi,

Q3:
Do we have to think of the size of the memory? The record number is long. Does it imply the db file might be huge? If it does, implements full-cachintg might loose marks. Suppose record mumber is int, should we think of the size of the memory?

You say: "The record number is long."
I certainly was suspicious when my DBMain method used an int for the record number;
and, it annoys me somewhat since I feel that it should be a long instead (though, Java
signed ints can get pretty large).
Presumably, for past projects, whose specifications may be different from yours,
loading the complete file into memory may have been okay (assuming that it
was appropriately justified).
I personally am not concerning myself too much with this issue until I have
a rough operational program; at that time, I can start to create large files,
think about just how big this database file might get, and so forth: for instance,
will I place a check into my software to determine if the record number has
gotten larger than an int value can hold?

Do we have to think of the size of the memory?

Generally, you can think and should think about all these issues. This, as is
my understanding, is part of the assignment. And, what your final decisions
are and their justifications are also part of the assignment.
There is a page on this web site dealing in general with the different approaches
people took, and many of these different approaches passed. Probably they
passed because they justified their particular approach.
As I'm relatively new to this newsgroup, I hope others will feel free to correct
and mis-notions I may speak.
Thanks,
Javini Javono