Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Lock Manager - Remote or Serializable??

 
lev grevnin
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey all,
Just a quick clarification question. I didn't code it yet, but my ConnectionFactory (a remote object) returns a new Connection to each client (also a remote object). When Connection is created by ConnectionFactory it gives it a LockManager object (a private instance of ConnectionFactory). Suppose a few clients access the ConnectionFactory, grab their own Connection object and get a LockManager object out of it to perform lock() unlock() operations on it. My question is: does LockManager also need to be a remote object, or if i don't make it a remote object what each client will get from connectionInstance.getLockManager() will be just a copy of the private LockManager instance from the ConnectionFactory, and any changes made by one client to its (LockManager's) internal Map (the Map is used to track who owns which record) will not be visible to other clients LockManager internal Maps?
[ March 12, 2003: Message edited by: lev grevnin ]
[ March 12, 2003: Message edited by: lev grevnin ]
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

My question is: does LockManager also need to be a remote object, or if i don't make it a remote object what each client will get from connectionInstance.getLockManager() will be just a copy of the private LockManager instance from the ConnectionFactory, and any changes made by one client to its (LockManager's) internal Map (the Map is used to track who owns which record) will not be visible to other clients LockManager internal Maps?

In the implementation that you described, no, the lock manager doesn't need to be remote or serializable. Notice that the invocations of the lock manager methods are local to the caller, even though it may seem like remote calls. Your connection object stub is on the client, but your connection object itself lives in the server JVM, and your lock manager also lives in the server JVM. When your connection object calls the methods of the lock manager, nothing is transported over the network when connection object communicates to the lock manager. But when the client gets the results from the server, the network transport takes place, and the carrier of these results (the connection object itself) therefore needs to be a UnicastRemoteObject (i.e. implement Remote and Serializable).
Eugene.
[ March 12, 2003: Message edited by: Eugene Kononov ]
 
lev grevnin
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Eugene, thanks a lot. Your reply was very helpful. It actually did clarify some of the things i was confused about. However... Imagine this situation:
On the client side i do:

will other clients (who will get their own Connection objects from ConnectionFactory) see the addition of the record # 123 to their LockManager's Map? It should be the same LockManager object for all Connection objects, I suppose, right? But if the LockManager is not a remote object, its COPY will be returned by connection.getLockManager() (for that to happen, LockManager has to be serializable of course). So how can any change done by one client on LockManager be visible to the other clients? (other than by performing lock() INSIDE one of Connection object's methods, because, indeed, this operation will be local to the server's JVM and EVERY Connection object on the client side will see this change)
any comments would help.
-lev
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

So how can any change done by one client on LockManager be visible to the other clients? (other than by performing lock() INSIDE one of Connection object's methods, because, indeed, this operation will be local to the server's JVM and EVERY Connection object on the client side will see this change)

The relationship between the Connection and LockManager is many to one (for a given database). That is, when your connection factory creates a connection object, that connection object constructor should take the reference to the same instance of lock manager that has been created already. If you have 20 clients who requested a connection to a database, you should have 1 instance of connection factory, 20 instances of connection objects, and 1 instance of the lock manager (which, again, was instantiated in the server JVM). Each of 20 instances of the connection object wraps the same instance of the lock manager. Therefore, when a client mutates the instance of the lock manager, every other client now points to a mutated object.
Eugene.
[ March 12, 2003: Message edited by: Eugene Kononov ]
 
lev grevnin
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Eugene. Your comments clarified things a lot.
-l
 
lev grevnin
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Eugene,

Each of 20 instances of the connection object wraps the same instance of the lock manager. Therefore, when a client mutates the instance of the lock manager, every other client now points to a mutated object.

This is entirely correct. However, this will only be true if any modification to the LockManager is done INSIDE the Connection's methods, called by client (so yeah, effectively it's the client which is initiating the change). If however, a client gets a LockManager object (must be Serializable) from Connection object, as in connection.getLockManager(), this LockManager object will be a COPY of the one shared internally between all Connections, and any changes to it will NOT be visible to the rest of the Connection objects. I actually tested this and it worked exactly as i described.
Just wanted to add this small comment/clarification.
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

However, this will only be true if any modification to the LockManager is done INSIDE the Connection's methods, called by client (so yeah, effectively it's the client which is initiating the change).

Right, and this is how it is supposed to be. The client never instantiates or mutates the instance of the lock manager directly, but through its remote reference to the connection object.
Eugene.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic