Re: Static in WO (was: Refresh)
Re: Static in WO (was: Refresh)
- Subject: Re: Static in WO (was: Refresh)
- From: Mike Schrag <email@hidden>
- Date: Thu, 1 Mar 2007 00:55:18 -0500
In Java, static variables are unique per-class-per-class-loader.
That is, if you have the same class loaded in two separate class
loaders, they will have independent static variables. Likewise,
obviously, if you run two JVM's, the static variables will not be
shared. WO instances each run in their own JVM's, completely
unshared (well, as far as you're concerned at the level you're
writing code). You can NOT count on static variables sharing across
instances. You can only count on static variables being available in
a SINGLE instance, and even then only in a SINGLE class loader
(though it just so happens that your entire app is loaded in a single
class loader, so that part isn't going to get you). If you're
counting on two instances of WO sharing a static variable, you better
start preparing yourself now, because you're about to have your heart
broken. If you need unique IDs across instances, there are several
techniques, but the least pain is to just use sequence generators
from your database and let the database handle the concurrency and
synchronization.
On Feb 28, 2007, at 9:32 PM, Florijan Stamenkovic wrote:
Hi Jerry,
Wow, this concept never really occurred to me. I indeed thought
that static variables ARE shared across applications running in the
same VM. I will have to test this, but supposing it is as you say
it is, I am screwed, because:
I have some code that synchronizes on a statically declared
variable in my SessionWorker class. SessionWorker is a class to
which RMI calls on Session are forwarded to. I use this
synchronization to generate unique numbers that are not keys in the
tables I am generating them in. I can not make keys out of them due
to their specific nature (it is guaranteed that the same table will
contain records with the same values in these fields, although in
another context they are unique). Thus the synchronization. I am
aware that even if my original idea is OK, and this works across
WOApp instances, it would only work on single machine deployment.
This concept starts to melt down.
Any comments or suggestions? Do I have to switch to stored
procedures to accomplish the above???
Singleton... I was so dumb to overlook that.
Many thanks for the info,
Florijan
Hi, Florijan,
The WOApplication class is a singleton for any WebObjects
application. From the first paragraph of the JavaDoc on
WOApplication:
The primary role of the WOApplication class is to coordinate the
handling of HTTP requests. Each application must have exactly
one WOApplication object. The application object receives...
Honestly, I've never considered the possibility that a static
variable declared for a class in one application is shared with
any other application using that same class within the same Java
Virtual Machine. I don't think this is true, and if it is, there
are a few things about static variables that I will have to
rethink before this bites me. Whether true or not, the variable
wouldn't be shared between JVM's.
That's why Robert Walker was suggesting scheduling outside the
application.
So... has anyone any information on static variables in a class
shared between separate applications on the JVM if two
applications use that same class?
Regards,
Jerry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40mdimension.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden