aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Singleton - Not quite so single.... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Singleton - Not quite so single...." Watch "Singleton - Not quite so single...." New topic
Author

Singleton - Not quite so single....

Chris Be
Ranch Hand

Joined: Sep 11, 2006
Posts: 36
All,

I found that despite using the Singleton pattern for the database (=restricting access to only one DB file per JVM), java (SDK) decides to start a separate JVM for each application launch anyway. (Also refer to WikiPedia Singleton Pattern Java for a reference to this situation.

This really makes the Singleton pattnern not quite work as singular as anticipated. The "customer" can still open multiple instances of the database implementation per file. Those instances can then potentially corrupt each other since locking is not coordinated between the instances.

Anyone came across this issue?

ChrisBe


ChrisBe<br />-------<br />SCJP, SCJD, SCEA in the making
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42264
    
  64
In the Java context, a Singleton is generally understood to mean "within one JVM", sometimes even just "within one classloader", so I'd say its use is somewhat inappropriate here.

If the application is aware that several instances of it can be running, then it's not hard to guard against this problem. A common way to prevent this is for the application to open a ServerSocket on a particular port. This will only succeed once, all app instances opened afterwards will get an exception, and should then quit.


Ping & DNS - my free Android networking tools app
Chris Be
Ranch Hand

Joined: Sep 11, 2006
Posts: 36
Thanks! So since it cannot be predicted/enforced that all java run instructions (e.g. java -jar as per task) on a particular machine always run in a single JVM, safeguarding against concurrent data file access is not possible on a programming level.

So as you suggest, Singleton, static reference etc. is then superflous work when trying to guard against accidental/intentional access concurrency on the same file (e.g. RMI server running on file, then standalone client being opened on same file, resulting in data corruption risk due to duplicate instance of lock object sets).

But since

You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server.


a multi-datafile acces scenario can be assumed as non-existent.

No worries.

[ UD: replaced CODE tags with QUOTE tags to preserve page layout ]
[ October 13, 2007: Message edited by: Ulf Dittmer ]
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968
    
    1

I love doing code testing and monitoring, and showing developers all of the various instances of their 'singletons' running on the JVM.

Much of this has to do with classloaders, and how classloaders load various Java classes. A singleton packaged and placed on various places on the classpath will potentially result in many instances of the singleton running.

Here's a good tutorial on classloaders if you're interested in learning more:

Classloading Demystified: Understanding J2EE JVM Classloaders at Runtime

-Cameron McKenzie
Chris Be
Ranch Hand

Joined: Sep 11, 2006
Posts: 36
Originally posted by Ulf Dittmer:
A common way to prevent this is for the application to open a ServerSocket on a particular port. This will only succeed once, all app instances opened afterwards will get an exception, and should then quit.


Another set of ideas to ensure application singularity per machine: Application Singularity
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Singleton - Not quite so single....