> 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.
Ok. I was not sure if one was more stable than the other.
> > 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
I figured that much, but I was not really sure.
> > 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.
That is not the behavior that I was seeing, perhaps your change to Queued*
fixed that. Not sure at the moment. I think I did find one rather large
application error, where the last MDB updated an entity, and then tried to
remove it (and all other related entities) at the end, all inside of one tx.
I made a dumb ass mistake and changed the method which removed these to be
NotSupported, which was causing a TX timeout waiting for the calling TX to
complete before anything could be removed... Since the last update never
commits, the database always looks inconsistent. Any ways, I think that this
was the problem that I was seeing with the Simple* lock.
> 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.
Cool. I will let you know if this fixes the problem I am seeing.
--jason
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
