K. Tsang CEng MBCS PMP PMI-ACP OCMJEA OCPJP
K. Tsang wrote:To answer your questions
2/ Data.class is part of the database. In stand-alone mode (without server), the app needs to talk to the database (hence the Data.class)
1/ If I understand your question correctly, I believe you are talking about "shutdown hook" on the server.
Say there are several clients/users connected to the server, then you kill (Ctrl+C) the server. A shutdown hook will allow the server to tell the clients that (server) is about to shutdown in X minutes, please log out blablabla.
Hope this helps.
Kerim Kara wrote:still though, why do we need locking method in single threaded environment in standalone mode ?
we lose some performance because synchronization and thread safety code in standalone mode.
is there a explanation for that one or am I missing something
Thanks
K. Tsang CEng MBCS PMP PMI-ACP OCMJEA OCPJP
Kerim Kara wrote:still though, why do we need locking method in single threaded environment in standalone mode ?
we lose some performance because synchronization and thread safety code in standalone mode.
is there a explanation for that one or am I missing something
K. Tsang wrote:For standalone mode, if you comment out the lock/unlock lines in create/update/delete methods, the app would function as expected.
Kerim Kara wrote:I will keep calling lock/unlock method in only rmi server
instructions.html wrote: // Locks a record so that it can only be updated or deleted by this client.
Roel De Nijs wrote:
Kerim Kara wrote:I will keep calling lock/unlock method in only rmi server
Then you'll be violating a must requirement. Because the interface you MUST implement clearly states for the lock-method:
instructions.html wrote: // Locks a record so that it can only be updated or deleted by this client.
So before you can update/delete a record, it must be locked! It doesn't matter in which mode your application is running in.
Kerim Kara wrote:Do we really need to use locking at which there is implicitly only one client in standalone mode?
Roel De Nijs wrote:
And if your must-to-implement interface states you have to call lock before being able to update/delete a record
Kerim Kara wrote:no I was thinking 2 service classes one calls data.lock before data.update /delete an the other one just calls data.update
Roel De Nijs wrote:
So in the update method you need to verify that the client who is updating this record was the client which locked the record (to prevent clientB from updating a record locked by clientA). But how will this check succeed in standalone mode, when you don't call the lock method
Kerim Kara wrote:how many client can you create in standalone mode ?
it is the running client and that's all(no rmi) , isn't it ?
Kerim Kara wrote:By the way I am using thread ids for locking not client id, I think I need to change that.
Kerim Kara wrote:I think it comes to point how you perceive Data.class. it should be used by both server and standalone modes.
Kerim Kara wrote:But to execute update regardless of mode , you must call lock() outside of update() method, which is sharing of some responsibility of update method in my opinion.
isn't it better to preserve atomicity of method by giving the responsibility of locking to caller by exposing lock method to caller ?
Kerim Kara wrote:and Roel Thank you for taking time to explain and respond promptly. I'd really appreciate that .
Roel De Nijs wrote:
Kerim Kara wrote:By the way I am using thread ids for locking not client id, I think I need to change that.
That's an easy one: if you use RMI, you can NOT rely on thread ids. Because there is no guarantee that subsequent requests of the same client are handled by the same thread.