How to share a singleton between threads (controller)
kheraud
I have to launch computation tasks which last long (in fact to dialog
with Apple Push Notification service for many smartphones). To do so I
plan to set up a Play! server and use Jobs launched by user
(authenticated) requests.
I need a way to trace jobs launched / finished / to be replayed... in
order not to have the same user launching two parallel jobs. To do so
I am trying to build a thread-safe singleton shared by controllers.
As in Play! all is based on static methods, am I doomed to have a
"singleton" with only static methods / fields. Is there a way to have
a singleton object instanciated and shared by controllers ?
Thanks for your help !
kheraud
Adam Jorgensen
--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
Karim Heraud
Adam Jorgensen
green
Karim Heraud
Adam Jorgensen
martin
if you have only one instance you can easily use singletons. Just
don't use Controller's static fields:
From Play's samples:
public class ChatRoom {
...
static ChatRoom instance = null;
public static ChatRoom get() {
if(instance == null) {
instance = new ChatRoom();
}
return instance;
}
}
If you are going to distribute your app to more instances, you can
simply extend your singleton to use an external storage later on.
Karim Heraud
Thanks a lot
green
Yann Simon
If 2 threads try to access the get() at the same time, you can have 2
instances at the end.
You need to synchronize the method, and use synchronisation inside the
method, with all the dangers it represent
(see 'The "Double-Checked Locking is Broken" Declaration':
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html)
If you do not need lazy loading of the singleton, use directly:
public class ChatRoom {
private static final ChatRoom instance = new ChatRoom();
public static ChatRoom get() { return instance; }
}
If you need lazy loading, you can use an enum for this
public enum ChatRoom {
INSTANCE;
public static ChatRoom get() { return INSTANCE; }
// you can use the constructor for lazy loading
}
Do not forget that you have one singleton pro JVM.
To be more precise, you have one singleton pro classloader.
If 2 classloaders load the singleton, you will have 2 instances.
For more information, read:
http://java.sun.com/developer/technicalArticles/Programming/singletons/
Citation:
" Multiple Singletons Simultaneously Loaded by Different Class Loaders
When two class loaders load a class, you actually have two copies
of the class, and each one can have its own Singleton instance. That
is particularly relevant in servlets running in certain servlet
engines (iPlanet for example), where each servlet by default uses its
own class loader. Two different servlets accessing a joint Singleton
will, in fact, get two different objects.
Multiple class loaders occur more commonly than you might think.
When browsers load classes from the network for use by applets, they
use a separate class loader for each server address. Similarly, Jini
and RMI systems may use a separate class loader for the different code
bases from which they download class files. If your own system uses
custom class loaders, all the same issues may arise.
If loaded by different class loaders, two classes with the same
name, even the same package name, are treated as distinct -- even if,
in fact, they are byte-for-byte the same class. The different class
loaders represent different namespaces that distinguish classes (even
though the classes' names are the same), so that the two MySingleton
classes are in fact distinct. (See "Class Loaders as a Namespace
Mechanism" in Resources.) Since two Singleton objects belong to two
classes of the same name, it will appear at first glance that there
are two Singleton objects of the same class."
Yann
2011/8/5 Karim Heraud <khe...@gmail.com>:
martin
You are absolutely right
@ green
I still think starting with this kind of approach is a good idea. As I
said you can easily re factor this singleton later on to connect to an
external service, rather than using the local jvm to store your state.
Just use a well designed interface and you only have to change code in
the singleton class and nothing else.