Here is another bit of oddness, which I do not quite understand. I was
trolling through the logs of a run which has odd tx behavior and saw this at
the end:
<snip>
2001-08-20 18:20:18,894
com.boldfish.does.mailing.persistence.internal.MailingPOEJB@2q8an [Thread
Pool Worker-11] DEBUG - changing state from 1 to 2
2001-08-20 18:20:18,894
com.boldfish.does.mailing.persistence.internal.MailingPOEJB@2q8an [Thread
Pool Worker-11] INFO - bean marked as modified
2001-08-20 18:20:18,894 org.jboss.tm.TxManager [Thread Pool Worker-11] DEBUG
- suspended tx: TransactionImpl:XidImpl [FormatId=257,
GlobalId=eng-ecr3a//62, BranchQual=]
2001-08-20 18:20:18,894 org.jboss.tm.TxManager [Thread Pool Worker-11] DEBUG
- resumed tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=eng-ecr3a//62,
BranchQual=]
2001-08-20 18:20:18,895 org.jboss.ejb.plugins.LogInterceptor [Thread Pool
Worker-11] DEBUG - Invoke: [13]
cleanup(com.boldfish.does.job.persistence.JobHome:13)
2001-08-20 18:20:18,895 org.jboss.tm.TxManager [Thread Pool Worker-11] DEBUG
- suspended tx: TransactionImpl:XidImpl [FormatId=257,
GlobalId=eng-ecr3a//62, BranchQual=]
2001-08-20 18:20:18,895
com.boldfish.does.mailing.persistence.internal.MailingPOEJB@2q8an [Thread
Pool Worker-11] DEBUG - [ cleaning up MRI objects for job,
com.boldfish.does.job.persistence.JobHome:13 ]
2001-08-20 18:20:19,060 org.jboss.ejb.plugins.LogInterceptor [Thread Pool
Worker-11] DEBUG - Invoke: [13] getDetails()
2001-08-20 18:20:19,061 org.jboss.tm.TxCapsule [Thread Pool Worker-11] DEBUG
- Reused instance for tx=XidImpl [FormatId=257, GlobalId=eng-ecr3a//63,
BranchQual=]
2001-08-20 18:20:19,061 org.jboss.tm.TxManager [Thread Pool Worker-11] DEBUG
- began tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=eng-ecr3a//63,
BranchQual=]
</snip>
I left in some of the application logs to show that some bean has been
modified. The bit at the end is what is confusing me. It is resuing the
tx... but the tx it is reusing has not committed yet.
Perhaps I am reading this wrong, but... perhaps not. This is the tx that
occurs near the end of a run which completed successfully (acording to the
logs, but the last tx never commited and thus the database is out of sync).
--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
