Jason,
I'm going to combine multiple email replies into one. Please switch back to
QueuedPessimisticEJBLock. We're trying to make this the default for JBoss
since it scales better.
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jason
> Dillon
> Sent: Monday, August 20, 2001 7:06 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore()
>
>
> I am using commit option B, since it might be possible that
> another process
> is using the database... though I am 100% sure that I have sole access to
> the database I am using.
>
You probably already know this but ejbLoad will get called whenever the
entity becomes part of the transaction
> If I run the first producer with the first MDB offline, then
> connect the MDB
> everything seems to be fine. I have run a few tests through in
> this manner
> and I have not had problem yet, where as if I try to have the both up
> together it will work only once after all nodes have been started
> (usually)
> and will fail most times after that.
>
> I should be able to have more than one thread update a single
> entity at the
> same time (or rather ordered as the container dictates) right?
>
By "more than one thread" you mean more than one transaction? Yes, you can
have more than one transaction, but remember, this is pessimistic locking.
The entity will be locked until the transaction commits. All other accesses
to the entity will be blocked until the entity is committed by the first
transaction.
> >
> > so you see:
> > 1. setModified()
> > 2. ejbLoad
> >
> > So there is no ejbStore() in between setModified() and ejbLoad()?
>
> Correct. I also very rarly a javax.ejb.DuplicateKeyException,
> which happend
> to just pop up as I was running these tests.
>
> > I assume you're using commit option 'A'?
>
> Nope, option 'B'.
>
isModified only get's called before a storeEntity(ejbStore()) It does not
get called before an ejbLoad(). storeEntity will get called on a
transaction commit. Also when a finder or remove method is called, but only
beans within the transaction will get stored in this case.
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jason
> Dillon
> Sent: Monday, August 20, 2001 7:34 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] ejbLoad() on a modified bean w/o ejbStore()
>
>
> 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?
>
> The (5) MDB uses findByPrimaryKey to locate all of the beans (a,
> b, c & d).
>
> So, if there is an entity and modified by one thread under one tx, and
> another thread/tx does a findby, the first thread will loose its
> data due to
> a ejbLoad from the second?
>
Not at all. Remember. Pessimistic locking! Once an entity becomes part of
a tx, all other threads/transactions are blocked until the tx commits.
> This is essentially what I am seeing, though I can not really
> tell that this
I just found a bug in QueuedPessimisticEJBLock that may be causing this
problem.
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
