> -----Original Message----- > > 3) Prohibiting launching threads instead of forcing EJB-Container > > implementors to elliminate the possibility makes it easier to build > > EJB-Servers. > > I think that here you are right on target, it�s more or less what the spec > sais about this 'These functions (...) decrease the ability of the > container�s ability to properly manage the runtime environment' > > I think this is a lot of bla-bla to make it easier to develop ejb container.
It is not blah-blah. These constraints were put in the spec to *accomodate* server design. The fact that not every container utilizes these constraints does not make their purpose any less valid. > It�s the other part of the 'why' in the spec that I think is funny; how can > threads compromise security ?? I think you are missing the fact that sometimes the security of EJB containers is tied to the Thread. Ergo, thread management clearly has security implications. > > I've launched threads on my applications, in fact, you may do so from > > Servlets/JSPs (_that_ spec doesn't prohibit it). There are some > > maintenance tasks that I perform asychronously from threads; I think I > > could probably have coded some kind of client that continually hits a > > web page to perform them, but that would also had sprung other problems, > > mostly post-delivery. My point is there are such times in which > > spawining a thread IS the optimal solution. I hope this provides more > > information to identify which ARE and AREN'T the times when you should > > venture. > > Well, the spec may prohibit the enterprise bean to spawn a thread, but it > tells nothing about the enterprise bean calling another class that spawns a > thread. Same goes for the java.io package. No IO, no logging right .. 'an > enterprise bean must not etc.' now can I use logging (log4J for example) or > not .. The explanation is even more ridiculous : 'The file system api are > not well-suited for business components to access data. Business components > should use a resource manager API such as JDBC, to store data.' I can think > of a lot of things I might want to do with a simple call to a file system > where i don�t want or need the overhead of transactions. Besides, some > information I might need might only exist on the file system, or, one of my > business needs might simply be the creation of a flat file in some > pre-defined format, to send to my bank to make payments or whatever. This is > a legitimate business need to be implemented in enterprise applications. I > really do not understand the why behind this. You state, very clearly, the reason for these restrictions when you say "I don't want or need the overhead of transactions". It is the very lack of transactional integrity that makes file IO "unacceptable". The fact that you cheat and make it work does not change this fact. tim. > > > > My 2c, > > > > Juan Pablo Lorandi > > Chief Software Architect > > Code Foundry Ltd. > > [EMAIL PROTECTED] > > > > Barberstown, Straffan, Co. Kildare, Ireland. > > Tel: +353-1-6012050 Fax: +353-1-6012051 > > Mobile: +353-86-2157900 > > www.codefoundry.com > > > > > > > -----Original Message----- > > > From: A mailing list for Enterprise JavaBeans development > > > [mailto:[EMAIL PROTECTED]] On Behalf Of Tim Endres > > > Sent: Tuesday, July 23, 2002 2:56 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: Is Exec() allowed in EJB > > > > > > > > > You should never spawn threads. Ergo, you should not call exec(). tim. > > > > > > > Thanks for the reply. On the same lines, do you think it is ok to > > > > spawn java threads in helper classes that are used by the > > > EJB? Please > > > > note that the helper classes are part of the same "jar" > > > that contains > > > > the EJB. > > > > > > > > To re-state, what I want to know is this: The spec doesn't allow > > > > spawning threads from the bean classes, but is is it okay to use > > > > "synchronization" primitive and to spawn threads from the helper > > > > classes that are used by the beans? > > > > > > > > Thanks. > > > > > > > > Venki > > > > > > > > ----- Original Message ----- > > > > From: "Sven E. van ?t Veer" <[EMAIL PROTECTED]> > > > > To: "Venki" <[EMAIL PROTECTED]> > > > > Sent: Tuesday, July 23, 2002 8:35 AM > > > > Subject: RE: Is Exec() allowed in EJB > > > > > > > > > > > > > FAIK, The ERB spec does not allow this. I see no reason > > > however that > > > > helper > > > > > classes cannot do this. > > > > > > > > > > -----Original Message----- > > > > > From: A mailing list for Enterprise JavaBeans development > > > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Venki > > > > > Sent: Tuesday, July 23, 2002 9:05 AM > > > > > To: [EMAIL PROTECTED] > > > > > Subject: Fwd: Is Exec() allowed in EJB > > > > > > > > > > > > > > > I am resending the message as I the email that I sent earlier > > > > > bounced back. I apologize for any inconvenience. > > > > > > > > > > ==========================Forwarded > > > > > message========================== > > > > > > > > > > > > > > > Hi, > > > > > I have implemented a stateless session bean that calls a helper > > > > > class. I am spawn a process from a method in the helper > > > class using > > > > > runtime.exec(). > > > > > Given that spawning threads is not allowed in the EJB server > > > > environment. > > > > > Is spawning processes okay? Is it not equivalent to > > > spawning threads > > > > > which are nothing but light weight processes? > > > > > I need answers quite urgently. If anybody has > > > experience in this > > > > > pls do let me know. Thanks. > > > > > > > > > > Venki > > > > > > > > > > ----- End forwarded message ----- > > > > > > > > > > > > > > > > > ====================================================================== > > > > ===== > > > > > 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". > > > > > --- > > > > > Incoming mail is certified Virus Free. > > > > > Checked by AVG anti-virus system (http://www.grisoft.com). > > > > > Version: 6.0.377 / Virus Database: 211 - Release Date: 15/7/2002 > > > > > > > > > > --- > > > > > Outgoing mail is certified Virus Free. > > > > > Checked by AVG anti-virus system (http://www.grisoft.com). > > > > > Version: 6.0.377 / Virus Database: 211 - Release Date: 15/7/2002 > > > > > > > > > > > > > > > > ====================================================================== > > > > ===== > > > > 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".
