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?
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 ).
- 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?
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.