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
