This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
Please help.... This is a followup to the "check client id" post.. The following is the log output when two clients are running network mode against the server. The first client locks record 5, the second client trys to lock the entire database. The log shows that the first client is successful in locking record 5, the second client locks the first 4 records and waits on the 5th. Client 1 then releases the lock on record five, and the second client locks the remaining records in the database. When the second client trys to unlock the records in the database, notice how the Thread ID changes, so the lock logic doesn't think the second client owns the records previously locked. The Thread for the second client starts out as RMI TCP Connection(6)-127.0.0.1 then, after locking the database, CHANGES to RMI TCP Connection(7)-127.0.0.1
so the unlock method will fail since it thinks it is a different connection. I tried storing/comparing on the Thread itself, but got the same results.
C:\Program Files\Java\Duane\Development Certification\Program>java RegFBNSDataba se .\suncertify\db\db.db FBNSDbRemote - ScheduleDb is <suncertify.db.Data@750159> method lock() - Thread <RMI TCP Connection(4)-127.0.0.1> attempting lock Attemping to lock record <5> Lock on record <5 was successful for Thread <RMI TCP Connection(4)-127.0.0.1>Lo ckStatus = true ThreadID = Thread[RMI TCP Connection(4)-127.0.0.1,5,RMI Runtime]
When the second client trys to unlock the records in the database, notice how the Thread ID changes, so the lock logic doesn't think the second client owns the records previously locked.
Mark is in North Dakota on vacation, but he is likely to close this thread when he returns because exactly same issue is discussed in this thread, where you also participated. As it has been pointed out by many people here, RMI runtime makes no guarantees with respect to mapping remote object invocations to threads. Because of this, you should consider an RMI Factory approach to identify the clients. Eugene.