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

FBNS: Did anyone use a singleton Data.java with RMI?

 
Ian Wark
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi again.

I'm still umming and ahhing about whether to have one db per client or make sure that there is only one db. I have read that RMI may call remote methods from more than one thread, but I am unclear about whether it plays any role in how many instances of the db get created. I'm pretty sure that I determine that (using a connection factory etc. for multiple instances, or a singleton to make sure of just one instance) but I just wanted to ask this.

I am interested if anyone had a singleton db and used RMI. I'm getting the feeling this might be a simpler solution. :roll:
 
jiju ka
Ranch Hand
Posts: 308
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
if you use a singleton db, how are you going to maintain file writers and file readers.

I didn't do a singleton db.

I think it is better to have seperate writers and readers for each thread from a learning point of view. If you use a singletom db you will have to provide writers and readers or need to maintain a writer or reader pool. There may be other ways to get writers and readers. Like db itself can create a writer for each update or create.
 
Ian Wark
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi jiju ka,

Sorry for the delay.

I'm not sure I get you. Is it not possible to have both a file writer and a file reader open on the same instance? Are you talking about NIO? Could you elaborate a bit more?

My main reason for asking is that almost all of the methods in my Data.java that have anything to do with read/write operations have been synchronized. If I synchronize on a class object, then I am very tempted to change all of these methods to be not synchronized, so that I don't double lock (and possible cause deadlock). On the other hand, if I only ever have to worry about a single instance of Data.java, then not much need be changed. I am supposed to go for an easy solution...

I would definitely like to have multiple Data.java instances, I am just a bit afraid that I will be introducing too many changes to Data.java without enough justification. (Performance is not good enough).
 
Frans Janssen
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ian,

If you use a factory that creates db instances, you can indeed control how many instances are created. E.g. if your client creates a db instance when it is launched and uses this instance for all its requests, no more db instances will be created, no matter how many threads RMI decides to use.

I started out with a singleton db instance, but my assignment had the interface without the cookies and I came to realize that the only straightforward solution to uniquely identify my clients, was to create one db instance per client.

Frans.
 
Ian Wark
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for your input Frans.
 
Alan W Morgan
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey guys,

I too am struggling with singleton or not decision.

Frans - If you had the interface with the cookies would it have affected your decision on using a singleton or not ?
 
Frans Janssen
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by alanwmorgan @Y:
I too am struggling with singleton or not decision.

Frans - If you had the interface with the cookies would it have affected your decision on using a singleton or not ?

Yes, it would. I would have kept the Data class a singleton, because (in my design) the Data class did not contain any client-specific data, so no need to have more than one of it.

The reason why I would want Data to be singleton is that it HAS A collection of lock objects, which must be the same for all clients, so that only one client can lock a record. I solved it by making this collection a singleton, but design-wise I think it would have been cleaner if Data had been the singleton.

Frans.
 
Alan W Morgan
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Frans Janssen:

The reason why I would want Data to be singleton is that it HAS A collection of lock objects, which must be the same for all clients, so that only one client can lock a record. I solved it by making this collection a singleton, but design-wise I think it would have been cleaner if Data had been the singleton.


Frans - I don't quite get what you mean when you say :

"I would want Data to be singleton is that it HAS A collection of lock objects"

Are you saying that you implement the Data class as containing a collection of lock objects....say a Map of thread name to lock cookies/rec no or something like that ?
 
Alan W Morgan
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry - a Map of record nos to lock cookies makes far more sense...wasn't thinking of RMI when I started writing about threads.
 
Frans Janssen
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In fact my lockCollection is a map of record numbers to Data instance references. Because I create a Data instance for every client, I can use the Data reference as a sort of cookie to identify the client that owns a record lock.

Frans.
 
Zee Ho
Ranch Hand
Posts: 128
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think that is not a big deal to implement the singleton or not,. In the server, there is only instance will be passed to all the client . And in local mode, there is only one user and only one instance of Data, If you want to identify the client, search the forum, surely there are a lot of thread about this, but I think the most simple idea is to use a counter in the LockManager and assign it to the client as their unique Id.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic