It sounds very reasonable and makes much more sense than your 1st approach (to me). So I would just say: go for it (and don't forget to document in your choices.txt why you introduced a Room-object instead of working with a String, can't be hard to do).
Does this sound reasonable and make sense?
I can't use a Room-object in my Data class (so just worked with String)
I chose the singleton pattern applied to the Data class (with a record cache) and marked every method synchronized.
I used in my RoomBusinessService and in the GUI Room-objects.
Just to ensure you have it spot-on (because your explanation is a bit unclear and it seems you have a wrong understanding) a few remarks. You have to consider 2 very important things when you are developing your Data class.
Vlad Djordan wrote:I made my Data class a Singleton as well, however, I lock on record numbers. I think even the Sun interface
defines the lock as: "Locks a record so that it can only be updated or deleted by this client."
Thus I've only synchronized my search and create methods, while the others will lock on the record number.
Both approaches work, and some of the tests I've run including some tests found here all execute properly.
Vlad Djordan wrote:I've run a test available on the SCJD faq and all my runs completed successfully including incrementing the counter to the
limit of an int.