Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Message-ID: <24362959.1190681450605.JavaMail.jira@brutus>
Date: Mon, 24 Sep 2007 17:50:50 -0700 (PDT)
From: "Daniel Lee (JIRA)" <jira@apache.org>
To: dev@openjpa.apache.org
Subject: [jira] Commented: (OPENJPA-381) OpenJPA is not doing Optimistic
 locking when running in JEE evnironment
In-Reply-To: <5783412.1190429450726.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/OPENJPA-381?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530029 ]=20

Daniel Lee commented on OPENJPA-381:
------------------------------------

The following information was found "out of sync" between OpenJPA manual an=
d JPA standard.  If the default
transaction isolation level is set to "default", OpenJPA passes the control=
 to container to use whatever container's
default.  In that case, there is no guarantee of read-committed transaction=
 isolation nor optimistic locking.
OpenJPA user's guide need to be updated too.

In "Sun Microsystems JSR 220: Enterprise JavaBeansTM,Version 3.0 Java Persi=
stence API" Section 3.4:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
3.4 Optimistic Locking and Concurrency
This specification assumes the use of "optimistic locking". It assumes that=
 the databases to which persistence
units are mapped will be accessed by implementations using read-committed i=
solation (or a
vendor equivalent in which long-term read locks are not held), and that wri=
tes to the database typically
occur only when the flush method has been invoked=E2=80=94whether explicitl=
y by the application, or by the
persistence provider runtime in accordance with the flush mode setting. If =
a transaction is active, a compliant
implementation of this specification is permitted to write to the database =
immediately (i.e., whenever
a managed entity is updated, created, and/or removed), however, the configu=
ration of an
implementation to require such non-deferred database writes is outside the =
scope of this specification.
The configuration of the setting of optimistic lock modes is described in s=
ection 3.4.3. Applications that
prefer the use of pessimistic locking may require that database isolation l=
evels higher than read-committed
be in effect. The configuration of the setting of such database isolation l=
evels, however, is outside the
scope of this specification.

and in "Apache OpenJPA User's Guide" Section 2.6.17:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
2.6.17. openjpa.jdbc.TransactionIsolation
Property name: openjpa.jdbc.TransactionIsolation
Configuration API: org.apache.openjpa.jdbc.conf.JDBCConfiguration.getTransa=
ctionIsolation
Resource adaptor config-property: TransactionIsolation
Default: default
Possible values: default, none, read-committed, read-uncommitted, repeatabl=
e-read, serializable
Description: The JDBC transaction isolation level to use. See Section 4.5, =
" Setting the Transaction Isolation " [198f]or details.

> OpenJPA is not doing Optimistic locking when running in JEE evnironment
> -----------------------------------------------------------------------
>
>                 Key: OPENJPA-381
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-381
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: jdbc
>    Affects Versions: 1.0.0
>         Environment: JEE
>            Reporter: Daniel Lee
>             Fix For: 1.1.0
>
>
> The follwoing code seems to be leaving isolation level to -1 (default) in=
stead of setting a correct isolation level for the connections.  I think th=
is is not right because this is leaving the contianer to use its own defaul=
t isolation level.  It will be, for example, Repeatable-read when using IBM=
 WebShpere.
> in DataSourceFactory.java:
>     public static DecoratingDataSource installDBDictionary(DBDictionary d=
ict,
>         DecoratingDataSource ds, final JDBCConfiguration conf,
>         boolean factory2) {
>             ...
>             ccd.setTransactionIsolation(conf.getTransactionIsolationConst=
ant());
>             ...
>     }
> with the default value set in JDBCConfigurationImpl.java:
>     public JDBCConfigurationImpl(boolean derivations, boolean loadGlobals=
) {
>         super(false, false);
>         String[] aliases;
>         schema =3D addString("jdbc.Schema");
>         schemas =3D addStringList("jdbc.Schemas");
>         transactionIsolation =3D addInt("jdbc.TransactionIsolation");
>         aliases =3D new String[]{
>             "default", String.valueOf(-1),
>             "none", String.valueOf(Connection.TRANSACTION_NONE),
>             "read-committed", String.valueOf
>             (Connection.TRANSACTION_READ_COMMITTED),
>             "read-uncommitted", String.valueOf
>             (Connection.TRANSACTION_READ_UNCOMMITTED),
>             "repeatable-read", String.valueOf
>             (Connection.TRANSACTION_REPEATABLE_READ),
>             "serializable", String.valueOf(Connection.TRANSACTION_SERIALI=
ZABLE)
>         };
>         transactionIsolation.setAliases(aliases);
>         transactionIsolation.setDefault(aliases[0]);
>         transactionIsolation.set(-1);
>         transactionIsolation.setAliasListComprehensive(true);
>         ...
>     }
> The fix of this is to set it to "Read-Committed" which will make it in sy=
nc with JDBC direct connections.

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.