SCJP 5.0, SCJD URLyBird 1.3.3, OCMJEA 5 (SCEA) Factory Homes
Jari Timonen wrote:
UB 1.3.3 does not define lock cookie -> RMI Factory Design pattern is a must, since RMI does not guarantee single thread access to server from client.
Roel De Nijs wrote:
Jari Timonen wrote:
UB 1.3.3 does not define lock cookie -> RMI Factory Design pattern is a must, since RMI does not guarantee single thread access to server from client.
UB 1.3.1 also defines no lockCookie, but i didn't use the RMI factory design pattern. so it is not a must
SCJP 5.0, SCJD URLyBird 1.3.3, OCMJEA 5 (SCEA) Factory Homes
Vijay Sai wrote:Thanks Roel for your detailed explanation. I think Synchronizing entire method may impact some performance but that seem to be the simpler approach.
I wonder how many people used the 2nd option!? and how they implemented it? hope someone answers it, I'm curious to know.
Thank you,
Vijay
Jari Timonen wrote:
Roel De Nijs wrote:
Jari Timonen wrote:
UB 1.3.3 does not define lock cookie -> RMI Factory Design pattern is a must, since RMI does not guarantee single thread access to server from client.
UB 1.3.1 also defines no lockCookie, but i didn't use the RMI factory design pattern. so it is not a must
Ok. Maybe i'm just too accurate ;) But... there is then possibility, that thread that locks record and after that reads it, is different.
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
SCJP 5.0, SCJD URLyBird 1.3.3, OCMJEA 5 (SCEA) Factory Homes
Jari Timonen wrote:Thanks Andrew. I already hide my lock/unlock methods from RMI. Exposed only business methods. I'm using thread id as locking cookie inside Data-class
Roel De Nijs wrote:
Jari Timonen wrote:Thanks Andrew. I already hide my lock/unlock methods from RMI. Exposed only business methods. I'm using thread id as locking cookie inside Data-class
Sounds too simple to me, but maybe I am worried for nothing so to be sure you don't make mistake in the rmi part.
If you have an interface with a lockCookie you should use that one to make sure the right client locks/updates/unlocks the record. If you don't have a lockCookie in your interface, you should be aware that RMI doesnot guarantee that consecutive requests from 1 client are handled by the same thread.
Kind regards,
Roel
SCJP 5.0, SCJD URLyBird 1.3.3, OCMJEA 5 (SCEA) Factory Homes
Vijay Sai wrote:
1.get writelock
2. In the try /catch block - synchronize(RAF) and write to the db.
3. unlock in the finally block
Without deviation from the norm, progress is not possible - Zappa. Tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
|