aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX: unlock()-call in the finally-block of the book-method 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: unlock()-call in the finally-block of the book-method" Watch "NX: unlock()-call in the finally-block of the book-method" New topic
Author

NX: unlock()-call in the finally-block of the book-method

Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi everyone,
1. My book-method in the RoomAdapter-class looks like:

My question focusses on the finally -block. I'm checking if the cookie has a value different to 0. It can be that an exception occur before the record has been locked and thus the record shouldn't be unlocked.
I thought before to use a boolean like:

But the problem is that before the lockRecord completes an exception may occur (like RecordNotFoundException).
Thus I think to check if cookie has got a value different to zero is more sure.
Comments?
Thanks in advance
Ulrich
james airey
Ranch Hand

Joined: Dec 15, 2003
Posts: 41
you can get into a situation where you have a try catch block within exception code.
For example (excuse the pseudocode)
try
{
\\ some SQL Stuff
}
\\ handle exception
finally
{
try
{
myConn.close();
}
catch (Exception)
{
log("unable to close exception");
}
}
this might suit your situation.
Ken Krebs
Ranch Hand

Joined: Nov 27, 2002
Posts: 451
You might also want to just squirrel away a reference to the exception in your catch block and rethrow it after the finally block does its thing.


kktec<br />SCJP, SCWCD, SCJD<br />"What we observe is not nature itself, but nature exposed to our method of questioning." - Werner Heisenberg
Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi Ken, hi James,
thanks a lot for your help.
James, I propose to catch in the finally-block only the SecurityException:

Because I would like to propagate the other possible exceptions like remote exception back to the client.
What do you think about that?
Greetings
Ulrich
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Ulrich,
Solution 1: it's OK, provided you make sure that you never generate a zero-cookie.
Solution 2: better IMO.
But the problem is that before the lockRecord completes an exception may occur (like RecordNotFoundException).
Thus I think to check if cookie has got a value different to zero is more sure.

If your lockRecord() method throws any exception, your locked flag will never be set to true.
There is a 3rd solution, though, and I think it is safer and easier to use as well. Writing unlock in such a way that it simply returns in case the record to unlock is not locked.
It's easier, because you don't need the if(locked) in your finally block.
And it's safer too, because you don't need to care in lock() about a possible exception thrown in lock() *after* the record reference was put in your HashMap.
Regards,
Phil.
Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi Phil,
thanks for your help.

There is a 3rd solution, though, and I think it is safer and easier to use as well. Writing unlock in such a way that it simply returns in case the record to unlock is not locked.

Do you mean something like:

Greetings
Ulrich
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Ulrich,
Exactly that!
Best regards,
Phil.
Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi Phil,
thanks,
see you in Brussels
Ulrich
Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi Phil,
after have implemented your idea, I realized that I have to change also my update/delete implementation. I need some advices from you.
Before I had following solution:

But now I have changed my implementation due to two points:
1. Similar to our discussion concerning the unlock-method I could exchange the else - block with a simple return. Or do you think that in that case it's ok to keep the thrown SecurityException, because trying to delete or update a not locked Record consists a bigger violation than to unlock a not locked Record?
2. In my prior implementation I haven't checked if the locked Record is really locked by this client. I don't know if it's redundant to check this, because the reason of using the lockCookie consists just to verify if the locked record is the one locked by this client. Perhaps my explication is a little bit confusing, I hope it will be clear if I post my second implementation (I'm using the ConnectionFactory, one Data instance per client)

What do you think about that?
My first implementation works fine. If another client tries to delete this record, either it is allready as a Key-value in the HashMap, but the cookie is different, or it isn't, thus a NullPointerException will be thrown, signalizing an implementation error.
I would be very glad if you could comment my new implementation, referring to the two points mentioned above.
Thanks a lot in advance
Ulrich
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Ulrich,
1. I wouldn't change the delete/update implementations. The specs tell you that in case the record is not locked or is locked by another client, you have to throw a SecurityException. So I would just do it. In unlock though, the situation is quite different: the fact that you code your unlock() method in such a way that unlock() may be called multiple times by a given client (the right one!!) on a given record doesn't break any security rule. It may just be handy for the caller.
2. It's better to do both as you do in your second implementation IMO. You have your Data instance at hand, so the additional check doesn't cost you anything. What I don't know is which method the second code snippet is extracted from. What are you doing there exactly ?
Regards,
Phil.
[ February 01, 2004: Message edited by: Philippe Maquet ]
Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi Phil,
2. It's better to do both as you do in your second implementation IMO. You have your Data instance at hand, so the additional check doesn't cost you anything. What I don't know is which method the second code snippet is extracted from. What are you doing there exactly?

The snippet is exctracted from my delete method but it doesn't matter because the synchronized block is in both methods equal. After the synchronized block of course the handling is different, for example for the delete-method I will have a call :
, which is a static synchronized method.

Sounds reasonnable, doesn't it?
Thanks & Greetings
Ulrich
[ February 01, 2004: Message edited by: Ulrich Heeger ]
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Ulrich,
Sounds reasonnable, doesn't it?

Much more indeed! But I would have kept the previous snippet, just replacing the "return" statements by a your exception: remember that in your design, the fastest access (by key) is performed on the data instance.
Best,
Phil.
[ February 01, 2004: Message edited by: Philippe Maquet ]
Roel De Meester
Greenhorn

Joined: Dec 22, 2003
Posts: 10
Hi Ulrich,
From your snippet i see that you have put the validation (48hours + owner="") on the server. Another option is to move the validation to the Client. (The option that I choose).
Do you know of any argument pro/contra my option.
My only argumentation PRO my solution is "If validation change (48h->72h)there is no reason to stop the server".
Ken Krebs
Ranch Hand

Joined: Nov 27, 2002
Posts: 451
Roel,
Although it can be useful at times to perform some validation on the client, it is not a good practice for a server to rely on client code for validation as incorrect or nefarious behavior by the client code could cause corruption of data or security breaches or other problems. If you can reuse your server side validation code on the client to prevent an unnecessary roundtrip, then it can be helpful to usability and performance. To be reusable, the validation code must be independent of the client code.
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Roel,
My only argumentation PRO my solution is "If validation change (48h->72h)there is no reason to stop the server".

Your solution is acceptable, as far as it doesn't need to reconfigure your 50 clients . But it supposes that:
  • that time range property is managed server-side anyway;
  • your network system supports client callbacks.


  • Now there is still the network-overhead issue: if the records your clients may be able to work with represent a maximum of 10% of the database contents on average, the filtering itself is better handled server-side.
    Regards,
    Phil.
    PS: For those of you who were quick enough to have read my first reply before I changed it, you should have noticed that I changed my mind in that 2-minutes meantime...
    [ February 01, 2004: Message edited by: Philippe Maquet ]
    Ulrich Heeger
    Ranch Hand

    Joined: Jun 06, 2003
    Posts: 266
    Hi Phil,hi Roel,
    Phil:
    Much more indeed! But I would have kept the previous snippet, just replacing the "return" statements by a your exception: remember that in your design, the fastest access (by key) is performed on the data instance.

    Ok, Guru, like always you convinced me
    Roel,
    my 48h validation is made also at the client side, because I have the 2-tier solution and thus my business layer is implemented at the client side.
    Thanx & greetings
    Ulrich
    [ February 01, 2004: Message edited by: Ulrich Heeger ]
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: NX: unlock()-call in the finally-block of the book-method