Hrm... I think this is just me being confused about FormatId and GlobalId...
--jason
On Mon, 20 Aug 2001, Jason Dillon wrote:
> 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
