You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Daniel Lee (JIRA)" <ji...@apache.org> on 2007/09/22 04:50:50 UTC
[jira] Created: (OPENJPA-381) OpenJPA is not doing Optimistic
locking when running in JEE evnironment
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) instead of setting a correct isolation level for the connections. I think this is not right because this is leaving the contianer to use its own default isolation level. It will be, for example, Repeatable-read when using IBM WebShpere.
in DataSourceFactory.java:
public static DecoratingDataSource installDBDictionary(DBDictionary dict,
DecoratingDataSource ds, final JDBCConfiguration conf,
boolean factory2) {
...
ccd.setTransactionIsolation(conf.getTransactionIsolationConstant());
...
}
with the default value set in JDBCConfigurationImpl.java:
public JDBCConfigurationImpl(boolean derivations, boolean loadGlobals) {
super(false, false);
String[] aliases;
schema = addString("jdbc.Schema");
schemas = addStringList("jdbc.Schemas");
transactionIsolation = addInt("jdbc.TransactionIsolation");
aliases = 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_SERIALIZABLE)
};
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 sync with JDBC direct connections.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-381) OpenJPA is not doing Optimistic
locking when running in JEE evnironment
Posted by "Daniel Lee (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Lee resolved OPENJPA-381.
--------------------------------
Resolution: Invalid
The code is correct base on the OpenJPA User's Guide and it default setting is fine as long as OpenJPA passes TCK.
> 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) instead of setting a correct isolation level for the connections. I think this is not right because this is leaving the contianer to use its own default isolation level. It will be, for example, Repeatable-read when using IBM WebShpere.
> in DataSourceFactory.java:
> public static DecoratingDataSource installDBDictionary(DBDictionary dict,
> DecoratingDataSource ds, final JDBCConfiguration conf,
> boolean factory2) {
> ...
> ccd.setTransactionIsolation(conf.getTransactionIsolationConstant());
> ...
> }
> with the default value set in JDBCConfigurationImpl.java:
> public JDBCConfigurationImpl(boolean derivations, boolean loadGlobals) {
> super(false, false);
> String[] aliases;
> schema = addString("jdbc.Schema");
> schemas = addStringList("jdbc.Schemas");
> transactionIsolation = addInt("jdbc.TransactionIsolation");
> aliases = 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_SERIALIZABLE)
> };
> 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 sync with JDBC direct connections.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-381) OpenJPA is not doing Optimistic
locking when running in JEE evnironment
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530491 ]
Patrick Linskey commented on OPENJPA-381:
-----------------------------------------
The comments in this thread seem to discuss transaction isolation levels, and not optimistic locking. However, the subject states that OpenJPA is not doing optimistic locking. Maybe we can change the subject to better reflect the problem described?
Regarding the problem itself: I don't understand what the issue is. OpenJPA lets the container configure the default isolation level; the JPA spec describes behavior at read-committed. The JPA spec does not prohibit higher isolation levels, and to the best of my understanding, the optimistic locking requirements of the spec are obeyed when using repeatable-read. So, the only issue here is that in a WebSphere environment, the defaults might not allow as much read-concurrency as is possible with different configurations.
Before going too far down this path, we should ascertain whether or not the WebSphere drivers even allow changing the isolation level after a JTA-managed transaction has begun.
> 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) instead of setting a correct isolation level for the connections. I think this is not right because this is leaving the contianer to use its own default isolation level. It will be, for example, Repeatable-read when using IBM WebShpere.
> in DataSourceFactory.java:
> public static DecoratingDataSource installDBDictionary(DBDictionary dict,
> DecoratingDataSource ds, final JDBCConfiguration conf,
> boolean factory2) {
> ...
> ccd.setTransactionIsolation(conf.getTransactionIsolationConstant());
> ...
> }
> with the default value set in JDBCConfigurationImpl.java:
> public JDBCConfigurationImpl(boolean derivations, boolean loadGlobals) {
> super(false, false);
> String[] aliases;
> schema = addString("jdbc.Schema");
> schemas = addStringList("jdbc.Schemas");
> transactionIsolation = addInt("jdbc.TransactionIsolation");
> aliases = 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_SERIALIZABLE)
> };
> 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 sync with JDBC direct connections.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-381) OpenJPA is not doing Optimistic
locking when running in JEE evnironment
Posted by "Kevin Sutter (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530524 ]
Kevin Sutter commented on OPENJPA-381:
--------------------------------------
The referenced code in JDBCConfigurationImpl does not set the transaction isolation level. It is only setting up the field to house the transaction isolation level. This IntValue (transactionIsolation) will contain the extent (or parameters) of the transaction isolation level setting. The code block is setting the available values (aliases), the default value (-1), and whether the list is complete or not. So, I agree with Patrick that the blocks of code referenced do not constitute a problem.
Now, there still may be a problem with setting of proper isolation levels, but so far this Issue doesn't describe it. And, it may be limited to WebSphere (as Patrick has hinted at).
Concerning Patrick's last question:
> Before going too far down this path, we should ascertain whether or not the WebSphere drivers even allow changing the isolation level after a JTA-managed transaction has begun.
Correct. WebSphere doesn't allow the changing of the isolation levels after a JTA transaction has started. At least for shareable connections, I know this is true. For unshareable connections, this rule may be relaxed a bit. But, since we deal with shareable connections by default, that is definitely the most common scenario. So, as long as we are attempting to change the isolation levels between transactions, then we should be okay.
> 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) instead of setting a correct isolation level for the connections. I think this is not right because this is leaving the contianer to use its own default isolation level. It will be, for example, Repeatable-read when using IBM WebShpere.
> in DataSourceFactory.java:
> public static DecoratingDataSource installDBDictionary(DBDictionary dict,
> DecoratingDataSource ds, final JDBCConfiguration conf,
> boolean factory2) {
> ...
> ccd.setTransactionIsolation(conf.getTransactionIsolationConstant());
> ...
> }
> with the default value set in JDBCConfigurationImpl.java:
> public JDBCConfigurationImpl(boolean derivations, boolean loadGlobals) {
> super(false, false);
> String[] aliases;
> schema = addString("jdbc.Schema");
> schemas = addStringList("jdbc.Schemas");
> transactionIsolation = addInt("jdbc.TransactionIsolation");
> aliases = 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_SERIALIZABLE)
> };
> 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 sync with JDBC direct connections.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-381) OpenJPA is not doing Optimistic
locking when running in JEE evnironment
Posted by "Daniel Lee (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530029 ]
Daniel Lee commented on OPENJPA-381:
------------------------------------
The following information was found "out of sync" between OpenJPA manual and 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 Persistence API" Section 3.4:
=====================================================================================
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 isolation (or a
vendor equivalent in which long-term read locks are not held), and that writes to the database typically
occur only when the flush method has been invoked—whether explicitly 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 configuration 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 section 3.4.3. Applications that
prefer the use of pessimistic locking may require that database isolation levels higher than read-committed
be in effect. The configuration of the setting of such database isolation levels, however, is outside the
scope of this specification.
and in "Apache OpenJPA User's Guide" Section 2.6.17:
===================================================================================
2.6.17. openjpa.jdbc.TransactionIsolation
Property name: openjpa.jdbc.TransactionIsolation
Configuration API: org.apache.openjpa.jdbc.conf.JDBCConfiguration.getTransactionIsolation
Resource adaptor config-property: TransactionIsolation
Default: default
Possible values: default, none, read-committed, read-uncommitted, repeatable-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) instead of setting a correct isolation level for the connections. I think this is not right because this is leaving the contianer to use its own default isolation level. It will be, for example, Repeatable-read when using IBM WebShpere.
> in DataSourceFactory.java:
> public static DecoratingDataSource installDBDictionary(DBDictionary dict,
> DecoratingDataSource ds, final JDBCConfiguration conf,
> boolean factory2) {
> ...
> ccd.setTransactionIsolation(conf.getTransactionIsolationConstant());
> ...
> }
> with the default value set in JDBCConfigurationImpl.java:
> public JDBCConfigurationImpl(boolean derivations, boolean loadGlobals) {
> super(false, false);
> String[] aliases;
> schema = addString("jdbc.Schema");
> schemas = addStringList("jdbc.Schemas");
> transactionIsolation = addInt("jdbc.TransactionIsolation");
> aliases = 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_SERIALIZABLE)
> };
> 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 sync with JDBC direct connections.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.