gavin wrote:
eh?
I'm trying to think what you might mean by this .... how would clustering affect anything?
A single JVM ensures that a static field is only loaded once by the classloader. This is differnt in a J2EE Container. First of all you have different class loaders per JVM. But this is okay as each classloader is responsible for a single application and in most cases you can silgthly ignore this (if you use reflection you should load classes with correct classloader). The problem is distrubted programming and clustering. Normally containers use something build on top of JINI/RMI/Serialization to replicate the JVM heap to each cluster note. As clustering is only a matter of configuration from view of container and deployer you have to ensure that your code works as it should in a clustered, replicated environment. Having said this the single JVM gurantee of a classic member is not longer valid for a clustered mulit-JVM environment. Of course maybe we need a real clusterable VM that ensures static to be static but I cannot imagine that is is planed by Sun or any other JCP member.
In EJB spec static fields are forbidden due to the restriction of the replicated, clustered nature of J2EE containers. Singletons are another example for this. You should at least synchronize them into a mulit-classloader architecture but synchronized is not allowed into a EJB Container (but in a servelt container you should have no problems with it).
My intention is not to meet trouble halfway! I want is to be carefully, thats everything.
Any thougths, hints, stuff, advice, wisdom abouth this?
Login
FAQ
Search
