I use 3-tier mode and call lock method on the server. I passed, but I loss 36 point about Locking and 6 point about General Considerations , I do not know whether it due to 3-tier.
Congratulations! After analyzing all results I feel like 3-tier architecture is not a problem. There have been two people who got 100% for locking (Tony Morris has passed the test last week). I will make now a dangerous statement, but that is what I beileve to: I think that Sun doesn't want us to synhcronie all methods on this or any other mutex. They want us to use locking for overall thread-safety. That means that we should lock the record exclusively (not only other lock calls of this record should wait, but also read should wait till record is unlocked). To handle create or find, a lock with -1 as recNo can be used to lock the database. I think it breaches the requirements , because a locked record should be allowed to be read. Hovewer it seems (to me) to be a preffered solution by Sun to do it. I just have feeling that is a key to get best scores on locking regardless of 2/3 design. I, personally will not do it, because I beleive it is incorrect solution. So, I am pretty sure I will get 44 points (having a 2-tier architecture) also. I don't want to confuse anybody or so. I just wanted to express my feeling what should have been done to get best scores. I have to finish choices.txt and userguide.txt to finish my assignement. I will then shares with all of you my results, which would hopefully clear the main question in the topic. Best, Vlad
Hi All, I am just about happy with my DB layer, and have seen Andrews comment:
But I have not seen anything that anyone has posted that would lead to data corruption (apart from those who forget to do the check the record status after locking the record - and that applies no matter whether the locking is performed by client or server)
Can someone expand on "check the record status after locking the record". I check that the record has not been locked before locking. If so the thread will wait. All the locks are stored within Vector (as suggested in Max's book) The thread with the lock then performs an operation on the record(update, delete, etc). Once the operation has finish the lock is removed from the Vector and all the threads are notified. Is this correct? Thanks Chris
Hi Chris I think that what Andrew meant is that you need to check the record has not already been booked, get the lock, then check once more that the record has still not been booked (because another thread could have booked it while you were waiting for the lock). Otherwise you could be unknowingly overwriting someone else's booking, hence corrupting data. Michael
"One good thing about music - when it hits, you feel no pain" <P>Bob Marley
But the locking is only a logical lock that your server will use to indicate that nobody else can update the record that you want to update. It is not a physical lock on the record on disk preventing any unfriendly process from writing to the disk. This is separate from writing thread safe code which will hopefully prevent you from reading a record while it is in the process of being written to.
Thanks for your answer, Andrew. Somehow I'd managed to blur the distinction between basic thread-safety and transactional locking. The debate between 2-tier and 3-tier makes more sense now... I'm planning on submitting a 3-tier solution, although it's always possible I'll change my mind mid-implementation. I still think a case could be made for acquiring a lock on a record when the CSR first brings up the 'book this contractor' form, but unless one extended the DBMain interface, I agree it's a rather flawed solution. Thanks again, Janus
Joined: Jun 02, 2003
Im defecting to the dark side (two tier!!!). My interpretation of the requirements (and a voice in my head) tells me to do it. I just hope i won't be killed by the three tierers...
Mmh... no risk, anyway not by me. If you start hearing voices, I actually feel better that you move to the 2-tiers camp. Best, Phil.
... In the assignment I did, I showed records that were unavailable. However the user could not do anything with that record. ... Regards, Andrew
Do you have the locking mechanism preventing users from updating records that are already "owned" by having a "lock" on them? Or do you provide for this functionality by checking if a String value exists in the owner field of a particular record? In retrospect, it seems records should be prevented from being deleted or having their owner-fields updated by the locking mechanism, or else there wouldn't be an occassion for a SecurityException to occur for a GUI-user (since the only place i currently have my lock/unlock methods being used are in my DataAdapter methods for update and delte (lock-update(criteria)/delete(critera)-unlock)). Gosh i'm confused. Could anyone share their thoughts on this? Paul [ October 25, 2003: Message edited by: Paul Tongyoo ] [ October 25, 2003: Message edited by: Paul Tongyoo ]
Sun Certified Java Web Component Developer for J2EE v1.4<br />Sun Certified Java Developer for J2SE v1.4<br />Sun Certified Java Programmer for J2SE v1.4
Originally posted by Paul Tongyoo: Do you have the locking mechanism preventing users from updating records that are already "owned" by having a "lock" on them? Or do you provide for this functionality by checking if a String value exists in the owner field of a particular record?
No, my check was client side. If the client selected an unavailable record, then the status bar stated that the record was unavailable, and the "Book" button was disabled. That way if it was later decided that users of the application needed to be able to undo changes, then a simple change to the client application would be able to give them that functionality. If the server itself disallowed any changes, then the server would have to be changed later to add the new functionality.
Originally posted by Paul Tongyoo: In retrospect, it seems records should be prevented from being deleted or having their owner-fields updated by the locking mechanism, or else there wouldn't be an occassion for a SecurityException to occur for a GUI-user (since the only place i currently have my lock/unlock methods being used are in my DataAdapter methods for update and delte (lock-update(criteria)/delete(critera)-unlock)).
Perhaps. I think that Sun indicates that a SecurityException may be thrown if the client has not locked the record they are attempting to delete. But I don't think they have indicated any other criteria for that exception. A currently booked record might be one case, but then what happens if they want to delete dated records? Personally if you do have the indication that SecurityException is to be thrown if the record is not locked then that is the only time I would throw the SecurityException. I would not impose my criteria on the client. Regards, Andrew
After reading all this fat thread I prefer thin client. 1.The word "provide" for me is nothing more then "allow" , 2.The server "provides" (show for client) public methods: lock(row)(which resides in Data.class) and book(contructor_id)(which resides in SomeAdapter.class and does all lock/book/unlock job), this is a client's headache to choose which method is easier to run . Some mazohist (nothing personal ) can build another client in addition to my thin client to call all these methods directly. Server provides these methods anyway. My questions are more specifical: 1. Should I build some GUI administration on server side to allow deleting/creating/unbooking? 2. What a preferable way to encapsulate/use Data.class's methods? Extend this class by SomeAdapter and call super.lock() or include Data object as member in SomeAdapter and use data_cl_object.lock()? Which one is better and may be exists another one - the best? 3. Should I wait if I want to read all records or create record or delete record while somebody holds any record lock? 4. Can I update some record while somebody read/create/delete? [ October 26, 2003: Message edited by: Peter Kovgan ]
Nice to see that other people have the same troubles ;-}
I designed the client with implicit locking. Therfore, my client interface doens't provide any 'lock' or 'isLocked'-method. I just implemented an 'update', 'find', ..methods. These methods garantee atomic write access by using the 'lock' and 'unlock' of the Data Interface, but hide the locking from the client.
With my design choice I run into trouble when multiple users like to update the same record at time. I found a workaround by rereading the record and compare it with the record from the GUI-table. If these records don't equal, I show a message that the reccord is outdated.
There is still a little risk that both users success at the same time, however, it simplifies the implementation much.
I hope (;-}) that an explicit lock handling on the client is out of the assignement scope. I rather think about making a business layer with the appropriate business logic: * lock * test if already booked * update * unlock
However, I ran in the same naming interpretation confusion. I think, we just need to document it well, like we must do it for other decitions.
Thanks to people that lead this very interesting thread few years ago and to those who pump it on top of the forum, allowing me to read it.
There are 2 reply thats sound like my own doubt. Is someone can comment them ?
DBMain's locking mechanism simply sucks for low-level locking -- the comments specifically state that locking is only meant to prevent writing by different clients. But what about a thread that's mid-read when another thread comes along and rewrites the record? This makes no sense to me. I would synchronize -any- operation, read or write, for a given record. If you want to be a bit fancier, allow concurrent reads but no writing while reading and no reading while writing.
I think that Sun doesn't want us to synhcronie all methods on this or any other mutex. They want us to use locking for overall thread-safety. That means that we should lock the record exclusively (not only other lock calls of this record should wait, but also read should wait till record is unlocked). To handle create or find, a lock with -1 as recNo can be used to lock the database. I think it breaches the requirements , because a locked record should be allowed to be read. Hovewer it seems (to me) to be a preffered solution by Sun to do it.
I am implementing socket based solution, and of course there is no way to expose the methods to the client. But I think it's a matter of preference. However, handing the client business logic methods is crucial, and it even raises the issue of locking timeout since the server will no longer have a control over the unlocking mechanisim.
author and jackaroo
I am implementing socket based solution, and of course there is no way to expose the methods to the client.
Joined: Jun 10, 2005
Hi... Hummmm, Andrew what are you trying to say? it seems like you are giving a way a new insight? How a client can invoke DB methods? Almost all Socket based solution are not meant to be distributed application, I will make my server behave like an "Application" Server". The way clients communicate with my server is true the serialization of special classes. In fact I derived this from JavaMail API, I am implementing a SearchTerm -like class that's is sent by the client. This class encapsulates all the search criteria, it has a match() method which is then invoked on the server side. I think this is much easier than handing the client a handle to the database, as I said, it raises the potential of deadlocks, it may take forever if the client crashes while holding the lock of a record. Thus, this approach cries for Lock Timers. I am still very much interested on your approach regarding the first issue, I am having the feeling that you are thinking of something similar to CGI programs.
author and jackaroo
Perhaps we should start by ensuring that we are talking about the same thing when we talk about "exposing the method to the client".
From my perspective, I am talking about calling a lock() method on the client side and, as a result, having the Data class' lock() method called. You cannot directly call Data class' lock() method from the client using either RMI or Sockets - in both cases you must have some sort of proxy at the client. (This is all leaving out whether you want to call these methods over the network or not).
Now if you are developing a sockets solution, you already have at least two operations that you must support over the network - searching, and booking. So you already have to devise some method of encapsulating what the request is along with the relevant data, and sending that to the server. The server must be able to determine what you are requesting, and process it properly and then encapsulate a proper response (which may even be an exception) to send back to the client. And the client has to be able to differentiate between the two responses and handle them appropriately.
So you already have most of the logic worked out for two operations - it should not be any more difficult to expand that concept to handle all the methods of the Data class.
That is: there is no technical reason why you cannot expose the lock methods to the client application. Whether you choose to do this or not is a separate issue - one that is the subject of many posts in this topic .
By the way - if you haven't already looked at it, the command pattern can make the whole handling of differing requests via sockets much easier.
Hi I have a burning question!I will still go on and educate my self with the various tiers of application development! My question concerns Max's book that i would love to follow for my B&S assignment! What does he make use of, a 2 tier application or 3 tier application? And does he call expose the locking and locking to the clients? I know he uses the Adapter pattern does this in anyway allow the client application not interact with lock and unlock? Insights would be appreciated! Thanks
I checked the link you refered me to Andrew, it's very informative. I don't think that posting issues regarding the Command Pattern is relevant to this thread. I will post about this again after I re-engineer my communication design.
Is anybody that used the 2-tier approach having the cookies in the interface provided from Sun ? Can you tell me if this solution was accepted by the Sun examinators ?
I read the entire post twice, and I think there are success stories for both approaches.
But I am doing the B&S and my DBAccess interface that I need to code Data.java from has the following signatures:
Since they marked as public, doesn't this implicitly mean the lock/unlock methods must be exposed to client? Am I missing something?
Thanks, [ August 07, 2007: Message edited by: Mark Ebeling ]
GREAT DAY TO BE ALIVE - Beats the alternative!<br />
Joined: Oct 07, 2004
Hi Mark, There are 2 different things: the DB interface that is the access point to your database and the interface that you expose to the client ( this means the interface that you expose over RMI or sockets). You can choose to expose something similar with DB which was also my first ideea but it seems to be somehow not so efficient as exposing some thin interface containing only some business methods like book, find. I hope this helps. Regards Liviu
subject: Should lock methods be callable by the client