• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

remote database close

 
John Chien
Ranch Hand
Posts: 105
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I have already coded the Local database access.
The test result is OK.
I am concentrated on the remote database access now. I have already coded the ConnectionFactory and the RemoteDataAccess.
In the ConnectionFactory, I have a method called
getDataAccessObject() which will return a new
instance of RemoteDataAccessImpl object
public RemoteDataAccess getDataAccessObject() throws RemoteException {
return new RemoteDataAccessImpl();
}
Every client gets the same ConnectionFactory object from rmiregistroy. However, every client
gets different instance of RemoteDataAccess object.
The RemoteDataAccessImpl is coded as:
public class RemoteDataAccessImpl extends UnicastRemoteObject implements RemoteDataAccess {
Data database;
public RemoteDataAccessImpl(String dbname) {
database = new Data(dbname);
.................
}
By this way, every client actually has its own
instances of database object (Data); I believe all of the database instance objects can concurrently access the same database file (db.db). However, they are not the same instances.
There are several discussions in the forum about the remote database close. The conclusion is to release the lock instead of closing the database because the database is shared.
My question is :
Since each Data instance is independent, will the
close in one instance really affect the other client ? If the close will affect the other client, how about the openning of the database ?
Will other client get affected too ?
Thanks,
John Chien
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

By this way, every client actually has its own
instances of database object (Data);

A a common solution here is that all clients share the same reference to Data. In your design, since every client uses its own instance of Data, the synchronized keyword in all the methods of Data has no effect with respect to inter-client calls. That is, if one client is in the middle of the add() method, nothing stops the other client from running the find() method. Since there is ultimately only one file pointer, you will end up in a hell of a mess. You could conceivably come up with some synchronization scheme that uses an external object as a semaphore, but why go through all the trouble if there is a natural solution? If you are doing it for performance reasons, I believe you will be penalized.
Eugene.
[ March 12, 2003: Message edited by: Eugene Kononov ]
 
Jane Weil
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
FBNServer is responsible for two things:
1. create Data instance to opent the databse

<code>
db = new Data("./../classes/suncertify/db/db.db");
</code>
2. create LockManager

The two instances will be passed to factory implementaion, and in turn passed to RemoteData implementation.
When the server is terminated, the database will be automatically closed, because db instance is gone. If this is not right, please tell me where to close the database?
 
John Chien
Ranch Hand
Posts: 105
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Eugene:
Thank you for the response.
Apparently, my design is not quite right.
That was the reason I posted this topic.
Because even myself can not see the real sharing of the database. Thus, the key is to share the same database reference between different RemoteDataAccessImpl instances.
That means the Data should be created in the ConnectionFactoryImpl. The same Data reference is
used to create each RemoteDataAccessImpl class when the getDataAccessObject() method is called.
Cool !! I will fix it.
Thanks,
John Chien
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

That means the Data should be created in the ConnectionFactoryImpl. The same Data reference is
used to create each RemoteDataAccessImpl class when the getDataAccessObject() method is called.

Yeah, you got it.
Eugene.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic