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 PROTECTED]> 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 protected]) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-dev/mschrag% >>> 40mdimension.com >>> >>> This email sent to [EMAIL PROTECTED] >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/ >> jean_francois_veillette%40yahoo.ca >> >> This email sent to [EMAIL PROTECTED] > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
