But are all the methods in any kind of bean pertaining to transactions, particularly updates? What about a method call on a bean that aggregates two io bound read operations for whatever reason (getting data from the web, and getting corresponding data from your database for example). So the restriction if imposed just for acid, affects other uses.
rick ----- Original Message ----- From: "Saroj Kumar" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, September 23, 2002 6:12 AM Subject: RE: [JBoss-user] Re: Can an ejb function as a daemon? > This will break the ACID property no doubt. > > This must certainly be one of reasons behind not having threads in > beans. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of Pete Beck > Sent: Monday, September 23, 2002 3:06 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-user] Re: Can an ejb function as a daemon? > > > Wouldn't having multiple threads in a transaction break the ACID > principle anyway? > > Particular the consistency and isolation parts. > > Imagine the scenario: > Thread A reads object 1. > Thread B reads object 1. > Thread B updates object 1. > Thread A adds 1 to the value of object 1. > > In this transaction the value of the object can be changed by thread B, > thus providing inconsistency to thread A. > > On Sun, 2002-09-22 at 18:51, David Jencks wrote: > > 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 > > > -- > Peter Beck BEng (hons) - Managing Director, Electrostrata Ltd. > http://www.electrostrata.com --+-+-+-+-- Experts in e-business and > e-commerce > > > > ------------------------------------------------------- > 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
