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.
Hi all, I thought my design was ok, but I'm not so sure anymore. At any moment there can only be one instance of the Data class (implements Sun's DBAccess interface), right? Or maybe I should say: one instance per individual data file, or table if you think in RDBMS terms. Ok, this assigment only uses one datafile/table, but I know that some of you insist on an extendable solution... For standalone mode it's rather obvious there's only one Data instance. For network mode based on RMI I can't see why there should be more than one either. I bind one object and RMI creates different threads to operate on that object. So, why are there even discussions whether should Data be a Singleton or not? Hope I'm not completely off course with my train of thought. Regards, Marcel
Hi Marcel, You have started with the assumption that "At any moment there can only be one instance of the Data class". But this is not a requirement of the assignment, it is totally dependant on how you choose to implement the provided interface. The equally valid question could be "why are you only allowing one instance of the Data class?". And the answer to that should be in your design choices document . Not everybody has the same requirements for the assignment as you - even someone who is also doing URLyBird may have different requirements than you. One of the areas that could be different is in the signature of the lock method (I know of at least three different lock method signatures - there may be more). Some people are not allowed to return a cookie from the lock method, which means that they must use something else to identify the client who owns the lock. Typically this is the instance of the Data class itself. Note: You cannot use the thread as the identifier in RMI, as you are not guaranteed that two calls from the client to the server will be run by the same thread. So, as I said before, you have made a choice to only have a single instance of the Data class, and therefore you need to document it. But this decision will not suit everyones requirements, nor will those with the same requirements make the same choice. So of course there will be discussion. Regards, Andrew
Hello Andrew, Looks like I failed to really express myself. I just don't see how there could be several Data instances running at the same time...Whether I implement it that way seems totally irrelevant as I don't see a possible use for it. Using RMI each client looks up a reference to some remote object; that's one thing. The server, however, only binds one instance of Data. Ok, it could possibly bind several instances with different names for whatever reason, but I don't see a point in doing so. Even if, it's me who's got the control over that, since it's me who implements the server. Using standalone mode there's guaranteed to be only one client. That's the reason for me to argue that there won't be more than Data instance. Why should there be several? One instance per request or so? I may be stuborn or ignorant. So, if you see a scenario where my assuptions are wrong, please let me know. Regards, Marcel
author and jackaroo
Hi Marcel, There are two possible questions in your post:
What is the use of having multiple instances of Data
How can we have multiple instances of Data since RMI only returns a single instance of the bound object
In such a case you cannot pass a unique identifier into the Data class's lock or unlock method. You cannot use the thread number in this case, as one client may use two totally different threads to call the lock and unlock methods - this is under the control of RMI, and you cannot change that. Some people try to avoid this problem by having the book() method on the server, in which case they can write the code to ensure that only the locker of a record can unlock it. While this meets the overall functional requirements of the server application, it does not meet the specific requirements of the Data class's lock method. To meet the requirements of the Data class itself, you must track ownership within the Data class (or in a common class such as a lock manager which the Data class calls). Typically this is done by having a unique instance of the Data class for each connected client. You can then use the instance of the Data class as your identification. [list]How can we have multiple instances of Data since RMI only returns a single instance of the bound object. What you would need to do here is to bind a connection factory to your RMI registry rather than binding your actual server code itself. So instead of having code such as:
You would have code such as:
Obviously I am leaving out a lot of steps there - have to leave something for casual readers to work out for themselves - but hopefully you can see how this could now work. There is only one instance of the factory registered through RMI, but the factory method getUniqueServer() will generate a unique server for each client that connects, and that unique server can have it's own instance of the Data class.
Hope this helps. Regards, Andrew
Joined: Nov 22, 2008
Hope this helps.
It sure does. Thanks for your explanations. Regards, Marcel