*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX: Does this mean I MUST use multiple DB instances? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "NX: Does this mean I MUST use multiple DB instances?" Watch "NX: Does this mean I MUST use multiple DB instances?" New topic
Author

NX: Does this mean I MUST use multiple DB instances?

Morgan Bath
Ranch Hand

Joined: Jan 16, 2004
Posts: 196
"Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified ...."
What do they mean by handle? Does it mean it must be able to process requests in parallel, or does it mean I could have a single instance DB and sync the methods and so deal with the request sequentially? It depends totally on what they mean by HANDLE. Any takes?


Morgan
SCJP (1.4), SCJD (1.4), SCWCD (1.3), SCBCD (1.3)
Morgan Bath
Ranch Hand

Joined: Jan 16, 2004
Posts: 196
Originally posted by morgan bath:
"Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified ...."
What do they mean by handle? Does it mean it must be able to process requests in parallel, or does it mean I could have a single instance DB and sync the methods and so deal with the request sequentially? It depends totally on what they mean by HANDLE. Any takes?


On consideration I guess there is no true parallel and that as even multiple instances with in reality be handled one at a time as and when their thread has the CPU Im now leaning towards thinking the single instance is an allowable option.
Is this assignment going to drive me insane before I even start coding?
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
Hi,
I think you've already answered your own question, but just in case, one way of handling concurrent requests is to sequentialize them. That is, process one and make the others wait their turn.
Hope this helps,
George


Regards, George
SCJP, SCJD, SCWCD, SCBCD
Morgan Bath
Ranch Hand

Joined: Jan 16, 2004
Posts: 196
I like the singleton idea because I intend to hold the DB in memory, and I guess once you have a few hundred clients connecting things might get icky on the server.....
But , and forgive me if this is a newbie question, but im one of those wimpy programmers who uses commercial databases instead of making their own (ill never bitch about oracle ever again I swear *grin*) and it seems to me that with a single instance DB, that all I need to do to implement a locking system is to sync on the data for all methods.
Somehow that feels to simple and its probably wrong .... what am I missing?
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
Hi Morgan,
No need to apologize about using commercial databases, since in the real world almost no one would implement his own database as in the assignment. But remember the assignment is an academic exercise of sorts and therefore Sun decided it would be simpler (and maybe more importantly exercise more Java language programming skills) to have the user build his own datbase rather than use one of the freely available DBMS's. I think the way Sun wrote the assignment actually makes the candidate think about locking and synchronization problems more than if a commercial database was allowed. Also, had Sun allowed a commercial database it would have been more challenging for the grader (more setup required, and probably would have had to limited to one allowable db, perhaps MySQL?).
Your solution (DB cache) is different than my own solution. I know several people on the forum have gone this way and it has much to recommend it and is in some sense a better solution. But I think it's true to point out that a DB cache is not required and that people have done quite well directly accessing the database file (which to some people's thinking may be a simpler, easier to implement solution). So others on the forum are probably in a better position to answer questions about the pitfalls of using the DB cache. On the other hand, if you were to pursue directly accessing the database file you would have other issues of concern in addition to record locking, namely sequentializing concurrent access to the database file. So, pick your poison. In either case, you'll have fun and learn a lot.
Hope this helps,
George
Morgan Bath
Ranch Hand

Joined: Jan 16, 2004
Posts: 196
But most people seem to have a list of locked records stored somewhere, do I need to do that in a single instance DB with synced methods? It seems to me that having a lock on the entire db cache will work.
It seems less efficient for responce time, but unless a few hundred clients submit requests at a single time I doubt it would be noticed.
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
Hi Morgan,
Originally posted by morgan bath:
But most people seem to have a list of locked records stored somewhere, do I need to do that in a single instance DB with synced methods? It seems to me that having a lock on the entire db cache will work.
It seems less efficient for responce time, but unless a few hundred clients submit requests at a single time I doubt it would be noticed.

My apologies in advance if this response doesn't make much sense as it's coming at the end of long day. I haven't spent a lot of time thinking about a db cache (ok, really I haven't spent any time thinking about it), but aren't you effectively doing database locking rather than record locking. And if so, aren't you sacrificing a lot of concurrency in the bargain? So I guess I'm saying it might work but you might not be as happy with the performance as you might be if you implemented record locking.
Hope this makes sense (and then hope it helps),
George
Morgan Bath
Ranch Hand

Joined: Jan 16, 2004
Posts: 196
Originally posted by George Marinkovich:
Hi Morgan,
but aren't you effectively doing database locking rather than record locking. And if so, aren't you sacrificing a lot of concurrency in the bargain? So I guess I'm saying it might work but you might not be as happy with the performance as you might be if you implemented record locking.
George


Yes. But to what extent will the performance hit be noticable? The chances of two client submitting bookings at the same microsecond is pretty slim at best, and the time it take one alteration is such that you probably would not notice the delay.
One of my assumptions is that the system is to be used by a small (less than 100) team.
My specs simply demand locking functionality, not record locking. AM I taking dangerous assumptions for this task? Am I simpliffying too much?
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
How much of a performance hit it is probably depends on when and for how long one locks the record or database.
In my case, I lock the record when the user attempts to book the record. The record is locked while the record is read from the database, and while the user edits the customer id for the record. Only after the user has finished editing the customer id is the record unlocked. How long can this process take? I would guess the minimum time is something like 4 or 5 seconds, but the maximum time is basically infinite. While I have this record locked, users can still book any of the other records in the database, and can, in fact, read all of the records in the database. If I were locking the entire database (which is what I understand you are proposing) I would have at least a 4 or 5 second (best case) to inifinite (worst case) freeze on the entire database whenever a user booked a record. That doesn't sound acceptable to me. I don't have to envision hundreds of users to see this kind of delay, I will see this kind of delay with only two users if one of them is booking a record. So, in my case because of when and for how long I'm locking I think I needed record locking.
Now, maybe if you're only doing a lock/update/unlock then you're looking at a much shorter duration period during which the database is frozen and under those circumstances that could be acceptable. So, database locking in your case may well be acceptable, whereas in my case it would not. (However, if you're only doing a lock/update/unlock then you have to solve the stale record problem somehow). In general I think record locking is better than database locking, but I can't quantify that advantage without knowing the details of the locking scheme and even then a reasonable person may come to the conclusion that it's simply not a significant difference. However, it is hard for me to imagine a locking scheme in which record locking would be less performant than database locking.
Hope this helps,
George
Morgan Bath
Ranch Hand

Joined: Jan 16, 2004
Posts: 196
Two questions:
1) A stale record is a record that has been altered by another client so your view of it is out of date?
2) If you lock a record when a client views it does that mean your client program views only one record at a time? Or do you view all records in a table and lock when the user highlights a specific row - active locking?
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
Originally posted by morgan bath:
Two questions:
1) A stale record is a record that has been altered by another client so your view of it is out of date?
2) If you lock a record when a client views it does that mean your client program views only one record at a time? Or do you view all records in a table and lock when the user highlights a specific row - active locking?

1) Yes.
2) I lock it when the user highlights a specific row and then indicates that he wants to book the record (for example, by pressing a Book button).
The client views all the records by default, or some subset as determined by the search criteria entered by the user. I wouldn't say "active locking" because I've heard someone else use that term to refer to a scheme wherein merely highlighting a row causes an attempt to lock the record. That's a little too active for me! In my design the user has to both highlight a specific row and then press the Book button before an attempt to lock the record is made. I'm trying to discourage unnecessary locking in my design.
Hope this helps,
George
[ January 19, 2004: Message edited by: George Marinkovich ]
Morgan Bath
Ranch Hand

Joined: Jan 16, 2004
Posts: 196
Originally posted by George Marinkovich:

2) I lock it when the user highlights a specific row and then indicates that he wants to book the record (for example, by pressing a Book button).
The client views all the records by default, or some subset as determined by the search criteria entered by the user.
[ January 19, 2004: Message edited by: George Marinkovich ]

I have a few more questions for you then
1) You lock when you book, so how long would you estimate the record will be locked for? Few microseconds? Would you really notice if the whole db was locked for microseconds? Assuming one booking every few minutes as a busy day, the mathematical chance of having to wait is astronomically slim, and if you do its a few microseconds. Im not sure its worth the complexity to save the odd client the odd microsecond delay ... Or am I missing something else?
2) If by default you load all the records, why use a search function on the DB? Why not use a filter on the JTable? Less network traffic surely?
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
Originally posted by morgan bath:

1) You lock when you book, so how long would you estimate the record will be locked for?
2) If by default you load all the records, why use a search function on the DB?

1) Anywhere from 5 seconds to forever.
2) Because any new records entered into the database after the client was started would not appear in the JTable. Also, the user would be unable to refresh stale records except by trying to book each record one at a time. In my design the user can refreshs the entire JTable be searching with empty criteria. When the user does a search they get back the latest values for the records that have been written into the database file (they don't get pending updates however).
Hope this helps,
George
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: NX: Does this mean I MUST use multiple DB instances?