I'm not thinking of pure ejb per se, but maybe I have a session bean that wants to do a long query and at the same time be scraping data from another external source. No reason to do io bound operations in sequence.
Another really is making a service, such as a kind of data source etc, natural for one service with multiple threads. Maybe I'm not saying all this correctly. Within a true transaction, of course you want a known sequence, but I wasn't intending to imply transactions. But even there, the return of particular method could easily be an aggregate of two long transactions that really are separate anyway (say one sub-transaction for posting to an invoice, another posting to an audit log, which aren't coupled tightly). rick ----- Original Message ----- From: "David Jencks" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, September 22, 2002 1:51 PM Subject: Re: [JBoss-user] Re: Can an ejb function as a daemon? > I'd like to see a concrete example where you need several threads to be > working within the same transaction concurrently. Thinking about it it > seems to me that it might work ok if each thread only talked to one > resource manager (db) but that there would be no way to expect reproducible > results if 2 threads worked on one resource manager. (thread A writes data > d, thread B reads d. Results depend on who goes first). In any case it > seems to me that allowing multiple threads on one transaction can at best > reduce latency/request while doing nothing for throughput. > > I think this was one of the simplifications adopted by ejbs to make > distributed computing comprehensible...so far I still think its reasonable. > > Still, I'd like to see a scenario. > > thanks > david jencks > > On 2002.09.22 12:56:38 -0400 Rick LaBanca wrote: > > I agree with those reasons I suppose. If the need of safely doing multi > > threads within one ejb call were realized, the spec could accomodate them > > (if the consituents you mention are worrying about multi thread issues, > > an > > api to give concrete hints toward the state would actually help). > > > > Anyway, all I know is when I first started learning about ejb's, I found > > it > > a sorely lacking thing, especially in the area of services. I guess I am > > a > > purist, I really want them to achieve a nice generic platform and not > > have > > to do things outside j2ee for services, database etc.. I guess with > > mbeans > > being rolled in that would help (now if only cmp relations!) > > > > rick > > > > > > ----- Original Message ----- > > From: "David Jencks" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Sunday, September 22, 2002 10:33 AM > > Subject: Re: [JBoss-user] Re: Can an ejb function as a daemon? > > > > > > > Another reason might be that transaction and security contexts may not > > be > > > propagated to the child threads. Also, the jca 1.5 spec goes to some > > pains > > > to prevent 2 threads that import the same transaction from running at > > once: > > > in general the effects of running several threads within one > > transaction > > > may be difficult to predict, and I think it is appropriate to > > internally > > > prevent more than one thread working within a transaction as well. > > > > > > thanks > > > david jencks > > > > > > On 2002.09.22 09:30:42 -0400 Rick LaBanca wrote: > > > > I think a session bean doing threads is not encouraged, but accessing > > > > something else that happens to be threaded could be ok. In my testing > > it > > > > is > > > > ok in jboss right now anyway, I do spawn off threads for multiple > > > > requests. > > > > > > > > I really don't understand the restriction anyway. So long as your > > > > response > > > > to a call in a session bean blocks until all internal threads are > > done, > > I > > > > can't see why the server would care. > > > > > > > > I think what they mean to restrict is a bean spawning a thread, then > > > > returning he original call while it runs. Then the container could > > try > > to > > > > passivate something really running. So using threads within one > > blocking > > > > call of a bean should be safe. Wish it was clearer. > > > > > > > > In fact I wish they would just allow it for those that need it in the > > > > case I > > > > mentioned too. All they need do is has a call to either poll a bean > > to > > > > see > > > > if it's active or not, or have the bean do callbacks to indicate when > > > > it's > > > > idle (no threads running). > > > > > > > > Rick > > > > > > > > > > > > > > > > > Isn't accessing threading facilities a no no in session beans? If > > you > > > > > have a deamon like service then I assume that it's multi threaded, > > so > > > > is > > > > > calling your singleton in effect breaking the ejb rules? > > > > > > > > > > How do other people deal with this. I've recently had the need to > > > > access > > > > > a file based content store from session beans and considered > > creating > > a > > > > > jca module. Is this the right way to do it? > > > > > > > > > > -k. > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > This sf.net email is sponsored by:ThinkGeek > > > > > Welcome to geek heaven. > > > > > http://thinkgeek.com/sf > > > > > _______________________________________________ > > > > > JBoss-user mailing list > > > > > [EMAIL PROTECTED] > > > > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This sf.net email is sponsored by:ThinkGeek > > > > Welcome to geek heaven. > > > > http://thinkgeek.com/sf > > > > _______________________________________________ > > > > JBoss-user mailing list > > > > [EMAIL PROTECTED] > > > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by:ThinkGeek > > > Welcome to geek heaven. > > > http://thinkgeek.com/sf > > > _______________________________________________ > > > JBoss-user mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > JBoss-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
