[EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Alex
> Loubyansky
> Sent: Monday, January 06, 2003 8:37 AM
> To: Muntean Horia
> Subject: Re[2]: [JBoss-user] Optimistic locking ported to JBoss-3.2
>
>
> Hello Muntean,
>
> Monday, January 06, 2003, 4:43:25 PM,
Hello Muntean,
Monday, January 06, 2003, 4:43:25 PM, you wrote:
MH> Does it make any sense using commit-option A with "Instance Per
MH> Transaction" container (a.k.a optimistic lock policy)?
A small note: Instance Per Transaction doesn't mean an optimistic
locking policy will be used. The default
Alex Loubyansky wrote:
To setup optimistic locking, container configuration element
locking-policy should be set to
org.jboss.ejb.plugins.lock.JDBCOptimisticLock
and entity element in jbosscmp-jdbc.xml should have optimistic-locking
element.
Following are the possible configurations of optimisti
Thursday, December 26, 2002, 10:34:54 PM, you wrote:
DH> Using the Version Strategy as an example, if you have one app
DH> server talking to one database (equiv to commit-option B), will
DH> this make mostly-read transactions better or not make that much of a
DH> difference?
Actually, this is what
DJ> Just to make sure I understand: I think this relies on the database
DJ> transaction isolation level to be read committed or weaker?
Yes, currently, to be consistent, the tx level should be read committed.
I am thinking about the case of read uncommitted. Suppose, one tx
modified entity. Ano
Ah, thanks Alex! Unfortunately, answering some questions lead to more questions for
even better understanding ;-)
Using the Version Strategy as an example, if you have one app server talking to one
database (equiv to commit-option B), will this make mostly-read transactions better or
not make t
On 2002.12.26 13:42:56 -0500 Alex Loubyansky wrote:
> DJ> I don't understand how this works yet. I'd really appreciate a
> detailed
> DJ> explanation of what happens when 2 threads/transactions
> simultaneously
> DJ> access one entity. I'd like to know what state the jboss "entity
> values"
> DJ>
On Thu, 26 Dec 2002 20:42:56 +0200, Alex Loubyansky <[EMAIL PROTECTED]>
wrote:
||| Well, I'll try to explain.
||| Suppose, we use version column strategy, i.e. counter column that will
||| be increased by 1 after each update.
Floyd Marinescu has a good explanation of this pattern in his book EJB
DJ> I don't understand how this works yet. I'd really appreciate a detailed
DJ> explanation of what happens when 2 threads/transactions simultaneously
DJ> access one entity. I'd like to know what state the jboss "entity values"
DJ> are in and what state the database is in at all points of such an
DJ>> Does this
DJ>> implementation result in each JBoss jta transaction getting its own copy of
DJ>> any entity it accesses?
AL> Here you caught me... it occurs it's not so great.
AL> Using "Standard CMP 2.x EntityBean" container entities are shared
AL> between transactions. So, if some tx changes
e I can figure
> out
> if I should use it)?
>
> Thanks,
> Hunter
>
> > From: Alex Loubyansky <[EMAIL PROTECTED]>
> > Reply-To: [EMAIL PROTECTED]
> > Date: Thu, 26 Dec 2002 18:12:36 +0200
> > To: David Jencks <[EMAIL PROTECTED]>
> > Subjec
26 Dec 2002 18:12:36 +0200
> To: David Jencks <[EMAIL PROTECTED]>
> Subject: Re[2]: [JBoss-user] Optimistic locking ported to JBoss-3.2
>
> DJ> Can you please explain how this implementation uses transactions and what
> DJ> transaction isolation settings it requires or
DJ> Can you please explain how this implementation uses transactions and what
DJ> transaction isolation settings it requires or assumes?
When transaction/new transaction comes, JDBCOptimisticLock locks
fields and their values depending on the strategy used. Fields and
field values are locked per e
This is great!!
Can you please explain how this implementation uses transactions and what
transaction isolation settings it requires or assumes? Does this
implementation result in each JBoss jta transaction getting its own copy of
any entity it accesses?
Is it possible to setup optimistic lockin
To setup optimistic locking, container configuration element
locking-policy should be set to
org.jboss.ejb.plugins.lock.JDBCOptimisticLock
and entity element in jbosscmp-jdbc.xml should have optimistic-locking
element.
Following are the possible configurations of optimistic-locking element:
1. Fix
15 matches
Mail list logo
