I am also seening some odd behavior where the final tx never gets commited.
I see the tx being suspended, then resumed, an application method log which
calls setModified(), then some more supend/resumes and then a few more
application methods. Then I get to an app method which will call a bunch of
removes() which runs under NotSupported. At this point the application
hangs and I will eventually get a tx timeout from the
SimplePessimisticEJBLock.doSchedule().
This behavior seems to be a bit irratic, as I could probably restart all of
the components and run it again just fine. But once it gets into a state of
funk, it is more or less non-functional from that point out.
--jason
On Mon, 20 Aug 2001, Bill Burke wrote:
> A thing to note. Whenever a finder or remove is called within a
> transaction, every entity of every type that is part of the transaction is
> synchronized with the database. Could this be your problem?
>
> Bill
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Jason
> > Dillon
> > Sent: Monday, August 20, 2001 6:39 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore()
> >
> >
> > I just checked an the same behavior exists with the
> > SimplePessimisticEJBLock. =(
> >
> > --jason
> >
> >
> > On Mon, 20 Aug 2001, Jason Dillon wrote:
> >
> > > I am running into another odd problem, this time it looks like
> > ejbLoad() is
> > > being called on a modified entity with out ejbStore() being
> > called first.
> > > I am not really sure why this would happen, nor do I know where to start
> > > looking.
> > >
> > > I am using isModified() to show that an entity has changed. The current
> > > impl simply logs a message and returns a boolean flag. I implemented a
> > > setModified(), which sets that flag to true and logs a message.
> > I am seeing
> > > bean is modified message, then shortly after on the same entity I see an
> > > ejbLoad() but there is no message about checking if the entity has been
> > > modified.
> > >
> > > This might be caused by two different threads accessing the
> > bean, so the tx
> > > might be confused... but it is my understanding that this should work.
> > >
> > > Essentially one user thread invokes a SFSB in a loop. This bean creates
> > > jms messages. A MDB on another machine does something with the
> > message and
> > > sends a response message back. Then another MDB in the same VM
> > as the SFSB
> > > takes the message and updates 3 entities that were created by
> > the SFSB to
> > > track the message.
> > >
> > > Due to this problem, the bookkeeping for the messages are
> > inconsistent, which
> > > more or less breaks the application completely.
> > >
> > > Is it possible that this might be caused by the new locking
> > system? I am
> > > currently use the QueuedPessimisticEJBLock locking policy on
> > all entities.
> > > I might try SimplePessimisticEJBLock, but I wanted to get some
> > input from
> > > the experts first, as to why this might be happening.
> > >
> > > At first I thought that there might be more than one Entity per PK being
> > > created, but I am not seeing that.
> > >
> > > If someone could advise me on where I can look to find out more how this
> > > works it would really be appreciated.
> > >
> > > --jason
> > >
> > >
> > > _______________________________________________
> > > Jboss-development mailing list
> > > [EMAIL PROTECTED]
> > > http://lists.sourceforge.net/lists/listinfo/jboss-development
> > >
> >
> >
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
>
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
