My URLyBird assignment defines a a database interface that does not allow passing any parameters other than a record identifier to the locking mechanism - nor returns any value. I believe this is done to drive me towards managing my locking mechanism by the clients threads. I have implemented this and my tests do not indicate any problem. However... The RMI specifications (http://java.sun.com/j2se/1.5.0/docs/guide/rmi/spec/rmi-arch3.html) state: "...The RMI runtime makes no guarantees with respect to mapping remote object invocations to threads...". (Boy - I wish Sun starts speaking English...) - The way I understand this is that my client can start the business functionality method call on the remote server with one thread - and end up with another - or whatever thread salad this may create. My question is this: Should I synchronize the business functionality method on my remote server - or not?
On one hand, my locking mechanism works perfectly without me synchronizing the entire method. In fact, why bother with this mechanism in the first place if I can just synchronize - making sure only one thread can modify a record at a time. On the other - if RMI makes no guaranty about which thread locks my record and which thread releases the locked record - could there be any other solution? Please - can any one with RMI experience help me?
Tom Silverman: SCJP5, SCJD6, SCWCD5, SCBCD5, IBM-142, ScrumMaster
if RMI makes no guaranty about which thread locks my record and which thread releases the locked record - could there be any other solution? Please - can any one with RMI experience help me?
so if your data interface don't return any value, you can take the current instance of data as identifier and provider you client with a unique instances of the data so every client will use this instance as identification for the lock and unlock.
so to generate multi instances of the data remotely, you can consider RMI Factory design pattern, that will provide unique instance for each client.
SCJP, SCJD in progress (from 1/8/2007 till now ).
Joined: Nov 01, 2008
Thank you for replying. I know this solution, plus the one with a token - It's in the excellent book SCJD Exam with J2SE 5 by Andrew Monkhouse, Terry Camerlengo, Mehran Habibi. Unfortunately, like I mentioned, the URLyBird 1.3.3 DBMain interface only allows the record identifier as the sole parameter. Take for example the following dictated locking methods:
public boolean isLocked(int id)
public void lock(int id) throws SomeException
public void unlock(int id) throws SomeException
Leave alone the factory design pattern implementation - at the bottom line - this interface does not allow passing in a unique object, token, magic voodoo thingy or anything but the record identifier, nor does it return anything. Besides - I really don't like the idea of distributing unique 'databases' objects. What if the DAO instantiation is an expensive process. What if it is not serializable? If this was a commercial RDBMS system would you distribute your DAO over the network to clients? I would not.
At some point I was considering an adapter pattern (i.e. an interface to an interface) but I got cold feet on account of the automated testing by Sun. I have no idea how they test and I would really like to stick to the interface that was provided. Like I said - I believe the sole 'id' parameter is not an accident and is intended for candidates to overcome the problem of identifying the client by the thread - despite the RMI specification restriction. I am not even sure if the above book interpreted the specs correctly. (but, hey, that's just me and I could be wrong). That's why I asked for experienced RMI help because go figure this:
"A method dispatched by the RMI runtime to a remote object implementation may or may not execute in a separate thread. The RMI runtime makes no guarantees with respect to mapping remote object invocations to threads. Since remote method invocation on the same remote object may execute concurrently, a remote object implementation needs to make sure its implementation is thread-safe."
Could this be any more obscured?
Joined: Sep 04, 2005
first of all , using adapter design pattern is a recommended pattern in any case of lock and unlock.
this interface does not allow passing in a unique object, token, magic voodoo thingy or anything but the record identifier, nor does it return anything.
if your lock method don't not take any more that recNo so you can use the "this" object as you create a unique instance for each clients of your application.
If this was a commercial RDBMS system would you distribute your DAO over the network to clients? I would not.
how tell you to register DAO instance, after you create adapter class that will adat an adaptee Dao instance you can use an adapter instances, sure that using RMI factory pattern.
Joined: Nov 01, 2008
Thank you so much. You have given me a new approach to an old idea. I'll give it a shot. Best regards.