You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Igor Fedorenko (JIRA)" <ji...@apache.org> on 2006/10/04 20:18:19 UTC
[jira] Created: (OPENJPA-63) Better pissimistic lock support for
DB2 v8.2+
Better pissimistic lock support for DB2 v8.2+
---------------------------------------------
Key: OPENJPA-63
URL: http://issues.apache.org/jira/browse/OPENJPA-63
Project: OpenJPA
Issue Type: Improvement
Components: jdbc
Environment: IBM DB2 UDB v8.2 or later
Reporter: Igor Fedorenko
There is new SELECT "FOR READ ONLY WITH RS USE AND KEEP EXCLUSIVE LOCKS" syntax in DB2 v8.2 and later that can be used to implement pessimistic locks for selects with multiple from tables, subselects, inner/outer joins and so forth. I'll attach simple patch shortly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OPENJPA-63) Better pessimistic lock support for
DB2 v8.2+
Posted by "Kevin Sutter (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OPENJPA-63?page=all ]
Kevin Sutter updated OPENJPA-63:
--------------------------------
Summary: Better pessimistic lock support for DB2 v8.2+ (was: Better pissimistic lock support for DB2 v8.2+)
> Better pessimistic lock support for DB2 v8.2+
> ---------------------------------------------
>
> Key: OPENJPA-63
> URL: http://issues.apache.org/jira/browse/OPENJPA-63
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Environment: IBM DB2 UDB v8.2 or later
> Reporter: Igor Fedorenko
> Attachments: db2-selectForUpdate.patch
>
>
> There is new SELECT "FOR READ ONLY WITH RS USE AND KEEP EXCLUSIVE LOCKS" syntax in DB2 v8.2 and later that can be used to implement pessimistic locks for selects with multiple from tables, subselects, inner/outer joins and so forth. I'll attach simple patch shortly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (OPENJPA-63) Better pessimistic lock support for
DB2 v8.2+
Posted by "Kevin Sutter (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OPENJPA-63?page=all ]
Kevin Sutter reassigned OPENJPA-63:
-----------------------------------
Assignee: Kevin Sutter
> Better pessimistic lock support for DB2 v8.2+
> ---------------------------------------------
>
> Key: OPENJPA-63
> URL: http://issues.apache.org/jira/browse/OPENJPA-63
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Environment: IBM DB2 UDB v8.2 or later
> Reporter: Igor Fedorenko
> Assigned To: Kevin Sutter
> Attachments: db2-selectForUpdate.patch, db2-selectForUpdate2.patch.diff
>
>
> There is new SELECT "FOR READ ONLY WITH RS USE AND KEEP EXCLUSIVE LOCKS" syntax in DB2 v8.2 and later that can be used to implement pessimistic locks for selects with multiple from tables, subselects, inner/outer joins and so forth. I'll attach simple patch shortly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (OPENJPA-63) Better pessimistic lock support for
DB2 v8.2+
Posted by "Kevin Sutter (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OPENJPA-63?page=all ]
Kevin Sutter resolved OPENJPA-63.
---------------------------------
Resolution: Fixed
I finally got around to verifying Igor's latest patch. It looks good and tests out okay on my system. Thanks for your patience, Igor.
> Better pessimistic lock support for DB2 v8.2+
> ---------------------------------------------
>
> Key: OPENJPA-63
> URL: http://issues.apache.org/jira/browse/OPENJPA-63
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Environment: IBM DB2 UDB v8.2 or later
> Reporter: Igor Fedorenko
> Assigned To: Kevin Sutter
> Attachments: db2-selectForUpdate.patch, db2-selectForUpdate2.patch.diff
>
>
> There is new SELECT "FOR READ ONLY WITH RS USE AND KEEP EXCLUSIVE LOCKS" syntax in DB2 v8.2 and later that can be used to implement pessimistic locks for selects with multiple from tables, subselects, inner/outer joins and so forth. I'll attach simple patch shortly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (OPENJPA-63) Better pessimistic lock support for DB2
v8.2+
Posted by "Kevin Sutter (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kevin Sutter closed OPENJPA-63.
-------------------------------
> Better pessimistic lock support for DB2 v8.2+
> ---------------------------------------------
>
> Key: OPENJPA-63
> URL: https://issues.apache.org/jira/browse/OPENJPA-63
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Environment: IBM DB2 UDB v8.2 or later
> Reporter: Igor Fedorenko
> Assigned To: Kevin Sutter
> Attachments: db2-selectForUpdate.patch, db2-selectForUpdate2.patch.diff
>
>
> There is new SELECT "FOR READ ONLY WITH RS USE AND KEEP EXCLUSIVE LOCKS" syntax in DB2 v8.2 and later that can be used to implement pessimistic locks for selects with multiple from tables, subselects, inner/outer joins and so forth. I'll attach simple patch shortly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OPENJPA-63) Better pessimistic lock support for
DB2 v8.2+
Posted by "Kevin Sutter (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OPENJPA-63?page=comments#action_12447595 ]
Kevin Sutter commented on OPENJPA-63:
-------------------------------------
A couple of items with this issue...
o Using the SELECT "FOR READ ONLY WITH RS USE AND KEEP EXCLUSIVE LOCKS" syntax for all forUpdateClause usages may be too much. One thing is that we may not need or want exclusive locks. Update locks would probably be sufficient. Should this be configurable?
o Along the same lines, what about the isolation level? Besides, the "with rs", we could specify "with cs", "with ur", or "with rr". RS and RR levels allow for the lock clause, the CS and UR levels do not. So, here again, it looks like it should be configurable. Or, at least determined at runtime based on the isolation level.
o Even for the optimistic locking case, the use of the "for read only" clause may be good for performance reasons on DB2.
o If we could determine a solid generic clause that would help your specific case, then I would be more in favor of modifying the DB2 Dictionary. For example, if "for read only" by itself would suffice, then I would be okay with using that for the forUpdateClause. But, if that would not provide enough isolation and locking facilities for your scenarion, then we might have to wait for a more generic solution.
o By accident, I attempted to run with your changes while running some other tests with WebSphere and DB2, and I found that the test conditions may not be sufficient. I was running with DB2 v8.2 and I got the following error:
DSRA8750W: The JDBC 3.0 method getDatabaseMajorVersion is not implemented on this JDBC Provider.
The trace showed the following datasource information:
[11/6/06 16:11:16:620 CST] 00000023 InternalDB2Da I DSRA8203I: Database product name : DB2/NT
[11/6/06 16:11:16:640 CST] 00000023 InternalDB2Da I DSRA8204I: Database product version : 08.02.0004
[11/6/06 16:11:16:650 CST] 00000023 InternalDB2Da I DSRA8205I: JDBC driver name : IBM DB2 JDBC 2.0 Type 2
[11/6/06 16:11:16:660 CST] 00000023 InternalDB2Da I DSRA8206I: JDBC driver version : 08.02.0004
[11/6/06 16:11:16:670 CST] 00000023 WSRdbDataSour I DSRA8208I: JDBC driver type : 2
So, we might have to check for more than just the database major and minor versions. This might also depend on the JDBC driver type. Not sure, I didn't check into that aspect of the solution just yet.
Given these discussion items, I'm not comfortable taking the patch as is. Igor, if you want to evaluate these comments and create an alternate patch, I would be interested in checking it out. Thanks.
Kevin
> Better pessimistic lock support for DB2 v8.2+
> ---------------------------------------------
>
> Key: OPENJPA-63
> URL: http://issues.apache.org/jira/browse/OPENJPA-63
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Environment: IBM DB2 UDB v8.2 or later
> Reporter: Igor Fedorenko
> Attachments: db2-selectForUpdate.patch
>
>
> There is new SELECT "FOR READ ONLY WITH RS USE AND KEEP EXCLUSIVE LOCKS" syntax in DB2 v8.2 and later that can be used to implement pessimistic locks for selects with multiple from tables, subselects, inner/outer joins and so forth. I'll attach simple patch shortly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OPENJPA-63) Better pessimistic lock support for
DB2 v8.2+
Posted by "Kevin Sutter (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OPENJPA-63?page=comments#action_12448584 ]
Kevin Sutter commented on OPENJPA-63:
-------------------------------------
Thanks, Igor, for your comments. I agree with you (and Patrick) that a general case solution is better than nothing at this point. If you can provide an updated patch, I will take another look at it and get it committed. Thanks.
One question though... In your first bullet reply, you said that you would change the lock clause to "..UPDATE LOCKS". But, in your "solid generic clause" reply, you said "..EXCLUSIVE LOCKS". I'm pretty sure that was just a copy-and-paste error, but I wanted to double check that you were going to use "..UPDATE LOCKS".
Thanks,
Kevin
> Better pessimistic lock support for DB2 v8.2+
> ---------------------------------------------
>
> Key: OPENJPA-63
> URL: http://issues.apache.org/jira/browse/OPENJPA-63
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Environment: IBM DB2 UDB v8.2 or later
> Reporter: Igor Fedorenko
> Attachments: db2-selectForUpdate.patch
>
>
> There is new SELECT "FOR READ ONLY WITH RS USE AND KEEP EXCLUSIVE LOCKS" syntax in DB2 v8.2 and later that can be used to implement pessimistic locks for selects with multiple from tables, subselects, inner/outer joins and so forth. I'll attach simple patch shortly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OPENJPA-63) Better pessimistic lock support for
DB2 v8.2+
Posted by "Igor Fedorenko (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OPENJPA-63?page=comments#action_12448377 ]
Igor Fedorenko commented on OPENJPA-63:
---------------------------------------
I guess I have not explained the problem I was trying to solve, so let me do that before I answer your specific questions.
Reading objects with ReadLockMode set to LockModeType.WRITE should create database locks necessary to prevent other concurrent transactions from using the same data. Here is a couple of relevant quotes from OpenJPA documentation: "pessimistic transactions generally lock the datastore records they act on, preventing other concurrent transactions from using the same data" and "PessimisticLockManager ... uses SELECT FOR UPDATE statements (or the database's equivalent) to lock the database rows corresponding to locked objects".
OpenJPA does NOT create any database locks for more complex SELECT statements (with MultipleTables, InnerJoin or OuterJoin). So I am asking to change OpenJPA such that it would be possible to prevent other concurrent transactions from using the same data with SELECT statements with MultipleTables, InnerJoin or OuterJoin for DB2 versions that support this.
Now to your questions.
o EXCLUSIVE vs UPDATE locks. Exposing fine-grained lock levels supported by DB2 is not necessary to solve this particular problem and should be tracked as a separate bugreport (if there is a need to provide such support in OpenJPA). Using UPDATE locks does seem more appropriate (see http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/admin/r0005274.htm) and I will provide updated patch.
o Use FOR READ ONLY with optimistic transactions. Indeed, this should be a separate enhancement request. I will update the patch not to include this (potential) performance optimization.
o Different isolation levels. Exposing different isolation levels is not necessary to solve this particular problem. For consistancy sake, I will update the patch to use the same isolation level as used in AbstractDB2Dictionary.
o Solid generic clause. I believe that "WITH RR USE AND KEEP EXCLUSIVE LOCKS" is the solid generic clause to address this particular locking problem. At very least it is much more generic than the very limited "FOR UPDATE WITH RR" clause current in use by OpenJPA.
o Use of JDBC 3.0 methods. Judging by "IBM DB2 JDBC 2.0 Type 2" log message, you're using old CLI DB2 JDBC which is not supported according to OpenJPA documentation (and is going to be removed from DB2 soon, according to the rumors). I will update the patch to fall back to current lock behaviour with JDBC 2.x and earlier drivers. I will test the patch with both CLI and JCC drivers with 8.2 and 9.1 and mayby with 8.1 too (I think I still have it around somewhere).
Hope this helps.
> Better pessimistic lock support for DB2 v8.2+
> ---------------------------------------------
>
> Key: OPENJPA-63
> URL: http://issues.apache.org/jira/browse/OPENJPA-63
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Environment: IBM DB2 UDB v8.2 or later
> Reporter: Igor Fedorenko
> Attachments: db2-selectForUpdate.patch
>
>
> There is new SELECT "FOR READ ONLY WITH RS USE AND KEEP EXCLUSIVE LOCKS" syntax in DB2 v8.2 and later that can be used to implement pessimistic locks for selects with multiple from tables, subselects, inner/outer joins and so forth. I'll attach simple patch shortly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OPENJPA-63) Better pessimistic lock support for
DB2 v8.2+
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OPENJPA-63?page=comments#action_12444414 ]
Patrick Linskey commented on OPENJPA-63:
----------------------------------------
For a change this small, I'm perfectly happy with doing the logic in a single class. We should keep an eye out for the logic diverging more and more, and create a separate class / subclass as needed at that time.
Also, Igor's changes to DelegatingDatabaseMetaData will have the unfortunate side-effect of requiring that we compile against JDK1.4 -- JDK1.3 java.sql.DelegatingDatabaseMetaData didn't have those two methods. Most of the methods in our JDBC package that throw exceptions do so to allow us to run against more recent versions of java.sql than we compile against. Personally, I'd rather maintain the OpenJPA 1.3 support. This, however, would require either doing some reflection (plus a call to DelegatingDatabaseMetaData.getInnermostDelegate()) in the DBDictionary, or just using SQL to ask the database about it's version, or getting the verison data from some other 1.3-supported source.
> Better pessimistic lock support for DB2 v8.2+
> ---------------------------------------------
>
> Key: OPENJPA-63
> URL: http://issues.apache.org/jira/browse/OPENJPA-63
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Environment: IBM DB2 UDB v8.2 or later
> Reporter: Igor Fedorenko
> Attachments: db2-selectForUpdate.patch
>
>
> There is new SELECT "FOR READ ONLY WITH RS USE AND KEEP EXCLUSIVE LOCKS" syntax in DB2 v8.2 and later that can be used to implement pessimistic locks for selects with multiple from tables, subselects, inner/outer joins and so forth. I'll attach simple patch shortly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OPENJPA-63) Better pissimistic lock support for
DB2 v8.2+
Posted by "Igor Fedorenko (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OPENJPA-63?page=all ]
Igor Fedorenko updated OPENJPA-63:
----------------------------------
Attachment: db2-selectForUpdate.patch
I ran the few unit tests that come with OpenJPA against DB2 and they worked.
> Better pissimistic lock support for DB2 v8.2+
> ---------------------------------------------
>
> Key: OPENJPA-63
> URL: http://issues.apache.org/jira/browse/OPENJPA-63
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Environment: IBM DB2 UDB v8.2 or later
> Reporter: Igor Fedorenko
> Attachments: db2-selectForUpdate.patch
>
>
> There is new SELECT "FOR READ ONLY WITH RS USE AND KEEP EXCLUSIVE LOCKS" syntax in DB2 v8.2 and later that can be used to implement pessimistic locks for selects with multiple from tables, subselects, inner/outer joins and so forth. I'll attach simple patch shortly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OPENJPA-63) Better pessimistic lock support for
DB2 v8.2+
Posted by "Igor Fedorenko (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OPENJPA-63?page=all ]
Igor Fedorenko updated OPENJPA-63:
----------------------------------
Attachment: db2-selectForUpdate2.patch.diff
Revised patch that uses "WITH RR USE AND KEEP UPDATE LOCKS" for-update clause and tolerates JDBC 2.x (read, "Legacy CLI") drivers. I tested this patch with DB2 8.2.2 (both JCC and CLI drivers) and with DB2 9.1 (JCC driver only).
> Better pessimistic lock support for DB2 v8.2+
> ---------------------------------------------
>
> Key: OPENJPA-63
> URL: http://issues.apache.org/jira/browse/OPENJPA-63
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Environment: IBM DB2 UDB v8.2 or later
> Reporter: Igor Fedorenko
> Attachments: db2-selectForUpdate.patch, db2-selectForUpdate2.patch.diff
>
>
> There is new SELECT "FOR READ ONLY WITH RS USE AND KEEP EXCLUSIVE LOCKS" syntax in DB2 v8.2 and later that can be used to implement pessimistic locks for selects with multiple from tables, subselects, inner/outer joins and so forth. I'll attach simple patch shortly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OPENJPA-63) Better pessimistic lock support for
DB2 v8.2+
Posted by "Kevin Sutter (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OPENJPA-63?page=comments#action_12444315 ]
Kevin Sutter commented on OPENJPA-63:
-------------------------------------
I was just taking a look at Igor's patch and it looks rather straight-forward. But, my general question is how do we (OpenJPA) want to support multiple versions of a given DB dictionary? Do we want a single dictionary and then do the version checks at runtime as Igor as presented? Or, do we want individual dictionaries for the versions that are supported and then load the right one based on the configuration? It seems like we could go either way. Is there a preference or a precedence that we should stick to?
Kevin
> Better pessimistic lock support for DB2 v8.2+
> ---------------------------------------------
>
> Key: OPENJPA-63
> URL: http://issues.apache.org/jira/browse/OPENJPA-63
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Environment: IBM DB2 UDB v8.2 or later
> Reporter: Igor Fedorenko
> Attachments: db2-selectForUpdate.patch
>
>
> There is new SELECT "FOR READ ONLY WITH RS USE AND KEEP EXCLUSIVE LOCKS" syntax in DB2 v8.2 and later that can be used to implement pessimistic locks for selects with multiple from tables, subselects, inner/outer joins and so forth. I'll attach simple patch shortly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OPENJPA-63) Better pessimistic lock support for
DB2 v8.2+
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OPENJPA-63?page=all ]
Patrick Linskey updated OPENJPA-63:
-----------------------------------
First, generally, I think that the patch is definitely an improvement. I agree that there are a bunch of things that we could (and probably should) parameterize. But as Igor points out, it's certainly better than what was already in OpenJPA. So we're moving in the right direction.
Re: JDBC3: if we execute on this decision to drop support for JDK1.3, then the issue is moot.
Also, this already is configurable at a coarse-grained level -- people can always set the forUpdateClause however they want, by setting the DBDictionary property to 'db2(ForUpdateClause="FOR UPDATE <MAGIC STRING HERE>").
> Better pessimistic lock support for DB2 v8.2+
> ---------------------------------------------
>
> Key: OPENJPA-63
> URL: http://issues.apache.org/jira/browse/OPENJPA-63
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Environment: IBM DB2 UDB v8.2 or later
> Reporter: Igor Fedorenko
> Attachments: db2-selectForUpdate.patch
>
>
> There is new SELECT "FOR READ ONLY WITH RS USE AND KEEP EXCLUSIVE LOCKS" syntax in DB2 v8.2 and later that can be used to implement pessimistic locks for selects with multiple from tables, subselects, inner/outer joins and so forth. I'll attach simple patch shortly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OPENJPA-63) Better pessimistic lock support for
DB2 v8.2+
Posted by "Kevin Sutter (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OPENJPA-63?page=comments#action_12445193 ]
Kevin Sutter commented on OPENJPA-63:
-------------------------------------
After requesting a vote via the dev mailing list, we've determined that we're not going to worry about supporting the back-level JDK 1.3 interfaces. So, Igor's usage of the new methods on DelegatingDatabaseMetaData should be okay.
> Better pessimistic lock support for DB2 v8.2+
> ---------------------------------------------
>
> Key: OPENJPA-63
> URL: http://issues.apache.org/jira/browse/OPENJPA-63
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Environment: IBM DB2 UDB v8.2 or later
> Reporter: Igor Fedorenko
> Attachments: db2-selectForUpdate.patch
>
>
> There is new SELECT "FOR READ ONLY WITH RS USE AND KEEP EXCLUSIVE LOCKS" syntax in DB2 v8.2 and later that can be used to implement pessimistic locks for selects with multiple from tables, subselects, inner/outer joins and so forth. I'll attach simple patch shortly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira