Are you in Brasil? Sao Paulo? Must be raining there... ;-) All inline
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: Sven E. van �t Veer [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, July 24, 2002 11:05 AM > To: Juan Pablo Lorandi > Subject: RE: Is Exec() allowed in EJB > > > > > > > 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. Actually, yes. It would be really difficult to implement a container so sturdy, it would have to resort to introspection all the time and a lot of indirection would be needed; that ain't cheap, either, it would add much more extra overhead to all method invocations only to support few exceptions. > > It�s the other part of the 'why' in the spec that I think is > funny; how can threads compromise security ?? The security/transactional information is transversal to the design. It is contextual. Since the current thread is always reachable by code, the usual way to write servers is to extend java.lang.Thread into a more specialized class that also tracks security and transactional activity. Also, usually, your app server runs under a security identity with a lot of permissions. Spawned threads (or processes with exec() )will have the same privileges on the system resources. It's a huge problem if you're providing hosting for these solutions; and is an exploitable feature even when you own the whole server and use it for just one app. This also is related to _some_ of the reasons to prohibit opening a ServerSocket; you could manufacture your own trojan, and the aims of the spec at the time were to be able to sell J2EE as the platform in which you'd be able to host EVEN business objects, something that in the M$ world few very corageous dare to. > > > 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. One of the things also that impacts your use of a file system is scalabilty and load balancing. Suppose you're using a load-balancer in round-robin and a cluster(machines A and B), and a user clicks on a page, the page executes in (A), it creates a file and sends a response. Then the user clicks to see the file, a page in (B) gets executed, cannot find the file in a local filesystem. This doesn't scare many of us, but it absolutely freaks the marketing teams(especially at the time the first J2EE was launched). That's why I often refer to the RDBMS as the "bottleneck we chose". I made money out of systems designed this way; I built a P2P file replicator to fix them ;-). Also, I think there is a JDBC driver around(called SimpleText?) that allows you to access a file like if it is a record on a table, with full transactional support. You can now write a .rar to handle it similary as well. But anyway there are many operations that are not only not transactional, sometimes they're read only. I don't see the point to go to lengths to conform so strictly to the spec, and it's my call(cuz it's my arse, and I also have to maintain the thing). DoTheSimplestThingThatCouldPossiblyWork is what some XPers would say(I don't agree with that all the time). The choice is ultimately ours. My responsibilities are, ultimately, with the paying customer. I go to him, tell him all of the options, the risks and the cost, and they always opt for the cheapest. And I've found out they're right most of the time they make these desitions, which is kinda scary. > > > > > 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". > > > > > > > ================================================================== > > ========= > > 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".
