So one way to interpret this is to go by what the spec says... But I think what would be more productive is to understand why the spec says what it says... My understanding is the following: The EJB spec was defined to allow for quick adoption by application server vendors, no matter what implementation language they use. Because of this, the EJB spec writers thought about different ways EJB may be implemented using different languages. One, possible solution would be to allow for a singe JVM or a separate JVM for each user, for each Bean, for each class of Bean and so on... In order to support these they've given some guidelines about statics. In the single case, statics work, you can change them all you want and all the other classes will be able to see them. Once you toss more then one JVM into the mix, the statics will not work because the values you set will only be reflected in the JVM you set them in... Now, the folks who wrote the spec know that simple global constants are useful so they tried to allow for that... Basically they want you to be able to do this: public static final int MY_CONST=1; but the idea was not to do this: public static final Hashtable MY_BAG_O_STUFF=new Hashtable(); and then try and share things between instances of the bean by stuffing stuff into the Hashtable... I'm sure you can see how in the first case no matter what JVM policy an EJB vendor uses, MY_CONST will always be the expected value, where in the second case MY_BAG_O_STUFF will not always contain the same items... (If you initialize the Hashtable in a static block using static values, you'd be ok...) No as far as not launching other threads, the restriction is there to protect transactionality. Basically, having everything occur in a single thread allows the EJB server to know what changes happen in what transaction, and to know that it is safe to commit/rollback a transaction because it is actually complete... If you had a method that started a transaction at the beginning, and ended it at the end of the method, but somewhere in the middle started a thread what happens if that thread lasts past the end of the transaction? And finally, why no JNI? If you have a server written in something other then Java and it pulls the VM in using JNI itself there are all kinds of potential problems where the two native libraries can harm each other... Better to do this stuff in a separate process space... So, I guess the other side of the coin is that depending on what EJB server you use you are safe cutting corners with these guidelines - but you do that with a trade off in portability.... -gabe Ron Yust wrote: > Javier, > > Does the fact that static objects work for you mean it is approved by the > spec, or maybe the ejb vendors haven't fully followed the spec, or you were > just lucky? > > When you say "singleton lookup tables of read-only data" do you mean a > static Hashtable can or can't be used to get/put data? > > -Ron > > > -----Original Message----- > > From: A mailing list for Enterprise JavaBeans development > > [mailto:[EMAIL PROTECTED]]On Behalf Of Javier Borrajo > > Sent: Tuesday, October 26, 1999 4:05 PM > > To: [EMAIL PROTECTED] > > Subject: Re: EJB Restrictions-- threads, io > > > > > > >I looked in the list, but these restrictions seemed to apply to the EJB > > Bean > > >itself. I understand the container-managed instance pooling imposes this > > >restriction somehow, although I dont understand exactly why. > > > > > >In particular, I'm wondering if static data can be moved into a utility > > >class which is created by the EJB bean code, and therefore get around the > > >static restriction. > > > > We do just that. It works with several EJB servers we have evaluated. > > We use singleton lookup tables of read only data implemented with static > > instances. > > > > Life's too hard without singletons ;-) > > > > BTW, we asked the same question in this list around March, I think. > > > > Regards > > > > Javier Borrajo > > www.tid.es > > > > ================================================================== > > ========= > > To unsubscribe, send email to [EMAIL PROTECTED] and include > > in the body > > of the message "signoff EJB-INTEREST". For general help, send email to > > [EMAIL PROTECTED] and include in the body of the message "help". > > > > > > =========================================================================== > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff EJB-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help".
begin: vcard fn: Gabriel Lawrence n: Lawrence;Gabriel org: Kovair<br>The power to .wow your customers. adr: 2 North First Street ;;Suite 212;San Jose;Ca;95113-1202;USA email;internet: [EMAIL PROTECTED] title: Architect tel;work: (408) 491-9731 note: The power to .wow your customers. x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard
