If the RMI stub is the localDataAccess, and it simply exposes on the client the public methods from Data(which implements DataInterface), then I don't see how I would be able to not call lock/unlock without some semaphore on the client to indicate mode. Maybe I have a wrong definition for localDataAccess?
For example, the client-side object in question could simply be the RMI stub for a DataInterface implementation that actually lives on the server (for specifics, search this forum for the "Connection" approach).
If the RMI stub is the localDataAccess
Maybe I have a wrong definition for localDataAccess?
That's fine because no actual locking is occuring, but couldn't you just as easily in your localDataAccess implementation not call lock or unlock at all? meaning have that code stripped out?
Originally posted by Mark Spritzler:
The is absolutely NO LOCKING in local mode. In local mode the app has exclusivity to the Data classes and db.db file.
If you feel that it is simply a waste of resources to implement locking in local mode, I counter with the fact that the database is intended to be reused by other applications and we cannot predict whether or not those applications would require multi-threaded access.
In this mode, the database and user interface run in the same VM and no networking is performed, and no sockets should be created.
Originally posted by Nate Johnson:
I assume you have finished the test... would you mind posting your score for the server section (sorry if you have done this already, I am a bit new here) since you did not have code in your local lock/unlock methods.