• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

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

 
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 266
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ulrich,
Exactly that!
Best regards,
Phil.
 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Phil,
thanks,
see you in Brussels
Ulrich
 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 266
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
    Posts: 266
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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 ]
     
    That's my roommate. He's kinda weird, but he always pays his half of the rent. And he gave me this tiny ad:
    Smokeless wood heat with a rocket mass heater
    https://woodheat.net
    reply
      Bookmark Topic Watch Topic
    • New Topic