File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Data wrapper Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Data wrapper" Watch "Data wrapper" New topic
Author

Data wrapper

Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
Hi All,
What is everyone's opinion on wrapping the Data class in a Singleton? What I have in mind is implementing lock, unlock and criteriaFind in the Singleton and the only modification that I make to the Data class is fix the deprecated methods. I would have two different Singleton classes (one for remote and one for local). I would return the appropriate Singleton based on a previously set property using lazy instantiation in a static getInstance() method. My DataAccess (and RemoteDataAccess) implemation class would interact with the Singleton.
I appreciate everyone's opinion
Michael Morris


Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
Laudney Ren
Ranch Hand

Joined: Jan 06, 2002
Posts: 111
Well, the main problem is "performance". When a lot of clients do such "reading functions" as criteriaFind(), they are accessing the same one thread, thus may result in bad performance.
And, please justify your choice of Singleton
Laudney Ren


" Veni, vidi, vici "<br />" I came, I saw, I conquered "
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
Hi Laudney,

And, please justify your choice of Singleton

Am I missing something here? How can there be more than one instance of Data and protect the ONE database file?

Well, the main problem is "performance". When a lot of clients do such "reading functions" as criteriaFind(), they are accessing the same one thread, thus may result in bad performance

Only one thread can go at a time anyway because I am synchronizing the criteriaFind() method (which calls other synchronzied methods of the Data class).
I'm not sure you understand what I'm proposing. There will be multiple client threads accessing the Singleton (which is essentially a proxy for the Data class). The remote Singleton also will manage all locking behavior, ie create a lock manager, verify that a record is locked before allowing modification, etc.
Michael Morris
Sai Prasad
Ranch Hand

Joined: Feb 25, 2002
Posts: 560
I would go a head with one Singleton Data class and a seperte LockManager class used only during remote access and implements pass through methods for lock, unlock and modify.
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
Hi Sai,
That's exactly what I had in mind.

Michael Morris
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by Michael Morris:
What is everyone's opinion on wrapping the Data class in a Singleton?
In short, a disastrous idea. I have seen Singleton mentioned as the single most often abused design pattern, and from my own observation this is patently true. Most Singletons are bad mistakes, poor OO design, and this is a prime example.
Disastrous? Mistake? Poor design? Surely everyone can't be wrong?
Creational patterns such as the Singleton should be used to encode fundamental properties and assumptions in your problem. The fact that you happen to need only a single copy of Data is not at all a reason to use the Singleton pattern. The question is, is there a fundamental reason why you can have only a single copy, both right now and in future revisions of the software?
Well, no. To the contrary.
Data represents a single database table. In years of developing databases, I have encountered only one (1) database with only a single table. That was the Fly By Night database. Every other database had at least two or three tables. If you want to write the database server code for re-use -- as you are asked to do! -- you cannot assume there will be only one data file and only one Data instance. Casting this assumption in concrete by employing the Singleton pattern would represent a deep and fundamental flaw in your design.
Now if you would devise a creational pattern that would enforce a single Data instance per data file, things would be altogether different.
- Peter
[ April 09, 2002: Message edited by: Peter den Haan ]
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
Hi Peter,
Thanks for the opinion. Consider the Singleton gone. I was uneasy about it anyway, hence the post. I guess now my problem is how do I best encapsulate the Data object. Do I instatiate it in my Connection Factory and pass a reference to the DataAccessImpl objects? Do I start it up in the server?
Thanks again
Michael Morris
Sai Prasad
Ranch Hand

Joined: Feb 25, 2002
Posts: 560
Peter,
It was a good explanation. I am still going to use Singleton but not in the Data class but in the sub classes of Data. Each sub class corresponds to one table and therefore one Data(sub class) instance.
I don't see anything wrong in using Singleton for sub classes of Data.
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
What unique behaviour would these subclasses have to justify their existence? Personally, I could justify exactly two DataInterface implementations: Data, and Connection (in fact in my submission Connection was an inner class called DataTableConnectionImpl ).
Consider something likeI'm not saying you should use this code as listed above. It all depends on your design and there are some loose ends too. I just wrote it to illustrate how you could implement a "per-file-singleton" creational pattern. This would be a good creational pattern to use, because there are very fundamental reasons why it is not safe to instantiate more than one Data object for one and the same file.
A more sophisticated version would use lock files to enforce the single-Data-per-file restriction even when the Data objects live in different JVMs (for example, the server is started twice).
Again I'm not saying you should do this (in fact I didn't personally) -- you may decide to leave it up to the programmer to ensure that there won't be more than one Data talking to a given file. This is one of those design issues that you need to think about, decide upon, and document.
- Peter
PS. The DataFactory should be a full-blown Singleton, though; I'll leave that as an exercise for the reader
[ April 10, 2002: Message edited by: Peter den Haan ]
Sai Prasad
Ranch Hand

Joined: Feb 25, 2002
Posts: 560
Peter,
I thought about this Factory to create Data instances. Like you said, the programmer needs to make sure he/she doesn't instantiate the Data instance directly.
Below are my justifications to create a sub classes of Data:
1) Constructors of Data have "protected" modifiers. So no one can create an instance of Data except the sub class instance.
2) criteriaFind() method in the spec needs to do wild-card like search for origin and destination if the user enters "any" for one or both of them.
In the criteriaFind() implementation, I use template pattern to let the sub class decide if the values typed in the screen and read from the table are equal or not. I can forsee more requirement like this for not only this table but other tables.
Make sense? Your comments please.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Data wrapper
 
Similar Threads
lock & unlock
Question from Andrew's book
Singleton / Factory decision
2 different types of singleton
Testing database/data layer without using Singleton method