I had a question about the Locking in the Data class. The client locks the record, makes the transaction and then unlocks the record. This is the normal case if everything is OK. It could happen that say Client A locks the record and before he completes the transaction, Client B unlocks the record. That would give erroneous results. (Of course this can happen only through a coding error) One way to get around this is to maintain a client tag/id with each record lock. I was considering making the Thread name(.toString()) the ID. But, RMI does not make any guarantees that it would use the same thread again for the connection. Also, cannot use the IP/DNS coz in case of a 2 connections throught a proxy server, they are same for both connections. I would appreciate any comments from you. Ashwin.
I think that if you use RMI, the only way to get/use a unique client ID is to pass it explicitly into all methods that modify the database. The ID could be assigned by the server the client connects to. It's not the most elegant solution, but I don't think Sun will mind as long as you motivate your choice. I think there are two alternatives: 1) Trust the clients to lock a record before they modify it. After all, you are writing the client yourself, but I admit that ultimately a database *server* is responsible for ensuring data integrity, not a *client*. 2) Use plain sockets. This has two distinct advantages: a) you can use Thread.currentThread() as the client ID, and b) you get rid of the RemoteExceptions you have to declare/catch everywhere with RMI. Regards, Remco.
The RemoteExceptions are there for a reason. They force one to think about the consequences of network problems. And believe me, network problems do happen. By forcing exception handling you are writing better code.
"People should get beat up for stating their beliefs" - TMBG
sunglasses are a type of coolness prosthetic. Check out the sunglasses on this tiny ad:
Devious Experiments for a Truly Passive Greenhouse!