This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Should lock methods be callable by the client Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Should lock methods be callable by the client" Watch "Should lock methods be callable by the client" New topic
Author

Should lock methods be callable by the client

Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Davidd,
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 !
so I hope my score could have some value for reference. I'll fell sorry if it is against Andrew.

If you lost points in locking because you handled it server-side, be reassured : it's against me in this thread.
Best,
Phil.
Davidd Smith
Ranch Hand

Joined: Jul 28, 2003
Posts: 62
Hi,
Philippe,
I am also sorry for that.
Regards
Davidd
Vlad Rabkin
Ranch Hand

Joined: Jul 07, 2003
Posts: 555
Hi Davidd,
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
Davidd Smith
Ranch Hand

Joined: Jul 28, 2003
Posts: 62
Hi,
Vlad,
Good luck!
Regards
Davidd
Chris Harris
Ranch Hand

Joined: Sep 21, 2003
Posts: 231
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


SCJP 1.2, SCWCD, SCBCD
Michael Fitzmaurice
Ranch Hand

Joined: Aug 22, 2001
Posts: 168
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
Dushy Inguva
Ranch Hand

Joined: Jun 24, 2003
Posts: 264
Guys,
Im defecting to the dark side (two tier!!!). My interpretation of the requirements (and a voice in my head) tells me to do it. :roll:
I just hope i won't be killed by the three tierers...
Dushy


SJCP, SCBCD, SJCD, SCDJWS, SCEA (Part I)
Janus Smythe
Greenhorn

Joined: Oct 19, 2003
Posts: 2
Originally posted by Andrew Monkhouse:

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
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Dushy,
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.
Paul Tongyoo
Ranch Hand

Joined: Sep 30, 2003
Posts: 91
Originally posted by Andrew Monkhouse:

...
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
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Originally posted by Philippe Maquet:
Hi Dushy,
If you start hearing voices, I actually feel better that you move to the 2-tiers camp.




The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Hi Paul,
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
Peter Kovgan
Ranch Hand

Joined: Sep 18, 2003
Posts: 84
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 ]
Janne Mattila
Ranch Hand

Joined: Jan 10, 2005
Posts: 32
Just passed the certification, and I remember reading this thread while wondering about the locking myself...I thought to provide my input:

I used 3-tier approach (client is not aware of locking), and got 80/80 on locking.
[ January 10, 2005: Message edited by: Janne Mattila ]
Kuno Snaglers
Greenhorn

Joined: Sep 28, 2005
Posts: 6
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.

Good luck!

Kuno
guillaume ame
Greenhorn

Joined: Aug 19, 2005
Posts: 5
Hi everyone,

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.
hatim osman
Ranch Hand

Joined: Jun 10, 2005
Posts: 105
Hi there...

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.

Hatim
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Hi Guillaume,

I think the questions you are asking are away from the topic of this post (which is long enough as it is). You will probably get better responses if you open a new topic for your questions.

Regards, Andrew
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Hi Hatim,
I am implementing socket based solution, and of course there is no way to expose the methods to the client.
Why not?

Regards, Andrew
hatim osman
Ranch Hand

Joined: Jun 10, 2005
Posts: 105
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.

Thanx
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Hi Hatim,

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.

Regards, Andrew
Saheed Adepoju
Ranch Hand

Joined: Jun 23, 2004
Posts: 267
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


Saheed Adepoju<br />SCJP 1.4<br />SCJD (B&S..In progress)
Seer Awad
Greenhorn

Joined: Oct 02, 2005
Posts: 3
Hi there...

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.

Thanx
Hatim
Liviu Carausu
Ranch Hand

Joined: Oct 07, 2004
Posts: 157
Hi ranchers,

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'm sorry for asking such stupid question but searching the forum I have found oly success stories based on 3 tier approach...

Thanks,

Liviu


Oracle Certified Master Java SE6 Developer(SCJD),
OCE JEE 6 JSP and Servlets Developer.
Mark Ebeling
Ranch Hand

Joined: Jul 06, 2007
Posts: 38
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 />
SCJP 5.0
Liviu Carausu
Ranch Hand

Joined: Oct 07, 2004
Posts: 157
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
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Should lock methods be callable by the client
 
Similar Threads
NX: Why do you all make LockManagers?
A question about Instructions
question on server binding
FBNS: Elegant design for client-side business classes
No need for a locking manager?