Re: Static in WO (was: Refresh)
Re: Static in WO (was: Refresh)
- Subject: Re: Static in WO (was: Refresh)
- From: netBrackets <email@hidden>
- Date: Thu, 01 Mar 2007 06:42:43 -0800
This is another possible solution that I always meant to investigate, but haven't up to now...
http://www-128.ibm.com/developerworks/java/library/j-ibmjava4/
On Thursday, March 01, 2007, at 08:35AM, "Jean-François Veillette" <email@hidden> wrote:
>I have never tried but, look at this demo, this look promising !
>
>- jfv
>
>Le 07-03-01 à 00:55, Mike Schrag a écrit :
>
>> 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:
>> email@hidden
>>
>> 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