This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I just started the Developer Cert, and I'm running into several questions, particularly with the database and record locking.
(I have the home improvement contractor assignment, by the way)
I see a lot of discussion about lockCookies. My assignment says nothing about them, and the method signatures would seem to prevent them. (public void lock(int recNo), etc.)
My main question is, is it safe to assume that my server will be the only client for this database? Without lock cookies, it seems that I would have to trust a thread to only unlock a record that it has currently locked.
Also, if all the locking is done server-side, it seems like it might as well all be done inside the create, update, and delete methods, rather than forcing the client to lock-modify-unlock.
If the lock is done inside the writing method, however, that means that a database client (still server-side) trying to do lock-modify-unlock, would create a deadlock.
So, the big question: If the GUI client cannot cause deadlock, and the exposed server methods cannot cause deadlock, am I safe, even though directly calling certain database methods could cause deadlock?
My main question is, is it safe to assume that my server will be the only client for this database? Without lock cookies, it seems that I would have to trust a thread to only unlock a record that it has currently locked
I guess you are trying to say is your server serves one client at a time... ifyour method doesn't inclcude cookie signature is oneway of good sign ..as you have broad choices for choosing cookie...I have long cookie in method for lock ...so i am bound to provide long cookie...Do you know why cookie is required??Its main purpose is to improve performance and less reliable synchronized methods..so your sequence goes like
lock-update-unlock in the lock you generate a cookie and check if this cookie is in the collection or not if so then you have to wait until its removed ..and once you got a chance ,you can put that cookie in collection and perform your update and in unlock you remove the cookie from collection .This way you can make sure at a time one client is updating ..Without Client identification (cookie stuff) how do you make sure this ??Hope this will help you ..and about lock call at client or server is like fat server or fat client issuse and your decision ...Either way is good..according to my methods i am forced to that calls at client side...Hope it helps...
SCJP 1.4<br />SCWCD 1.4(91%)<br />Working on SCJD -Bodgitt & Scrapper Constructions...<br /> <br />"It takes 43 muscles to frown & 17 to smile but it doen't take any to just sit there with a dumb look on your face .. Keep Smiling "
Joined: Oct 04, 2006
The description says I need to be able to support multiple simultaneous clients. My question is, do I know that every client accessing my server will be an instance of the client I wrote?
Based on the problem description, there's no need for clients to be able to lock records. The specified interface seems to prevent lock cookies, so is it possible that all locking should be done on the server side?
There is no need for your client to be calling lock or unlock. A call from the client to update a record should be atomic, not islocked->lock->update->unlock. Your server should be handling the details of locking. This is additionally good because it is way simpler to code.
Imagine it in the real world - you have a client that says - update this instance, and the server handles starting a transaction, locking the record, running the SQL then committing the transaction. You would never require your client program to know about transactions.
Its a pretty poor design to assume your client will handle locking/unlocking a record, because you can never guarantee that a client will implement it correctly. E.g. eBay would not rely on people writing third party clients to correctly handle locking their database!
I'm working on the same problem. There is one interface specified for use in the server and it's a "data access interface." The interface mandates lock, unlock, and isLocked method calls.
About lock cookies, there was another post about the the home improvement contractor assignment. It was noted that the data access interface did not specify RemoteException. For instance, public void lock(int recNo) throws RecordNotFoundException; The reply in that post hinted that it might be the case that the "data access interface" is different from the interface that a client sees. Solutions might be free to use more than one interface as long as one of them is from the assignment.
The assignent says that "must provide locking functionality as specified in the interface provided." If we interpret the words "data access interface" from the assignment instructions as applying to the server only some of the problems go away.
This leads to the next befuddlement. It's possible to solve the problem by implementing but not actually using the lock/unlock/isLocked interface -- synchronization statements alone are sufficient.
My take on this is that synchronization should be avoided. One benefit of implementing and using the lock/unlock/isLocked system is that you can build in timeouts. That would allow the application to cope with client crashes.
Another problem: the application has to be able to lock records before it deletes them. The assignment instructions also say that unlock method call throws an exception when called upon to remove the lock from a deleted record. The assignment instructions do not say whether or not the lock is actually removed in this case. This is probably yet another reason to hide the unlock method from client programs. Yuck.