[
https://issues.apache.org/jira/browse/JDO-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Craig L Russell resolved JDO-619.
---------------------------------
Resolution: Fixed
Most of these issues have been resolved with the JDO 3.0 release. If any issues
remain, please open another JIRA.
> API required for enabling/disabling FOR UPDATE locking for SELECTs
> ------------------------------------------------------------------
>
> Key: JDO-619
> URL: https://issues.apache.org/jira/browse/JDO-619
> Project: JDO
> Issue Type: New Feature
> Components: api, specification, tck
> Reporter: Marco
> Assignee: Craig L Russell
> Fix For: JDO 3
>
> Attachments: jdo619.patch
>
>
> We - http://www.jfire.org - have some code where it is essential that objects
> read from the datastore are not manipulated by another transaction before
> they are modified and written to the datastore. In SQL, you use "SELECT ...
> FOR UPDATE" for this purpose, which locks the records included in the query
> result till the end of the transaction just like a write operation does.
> In JDO, it is currently not yet possible to control whether reading causes
> read-locks (simple SELECT) or write-locks (SELECT ... FOR UPDATE). There are,
> however, vendor-specific solutions already. Thus, I'd like to first point out
> how DataNucleus solves this problem:
> 1) The page RDBMS persistence
> properties<http://www.datanucleus.org/products/accessplatform/rdbms/persistence_properties.html>
> describes the property "datanucleus.rdbms.useUpdateLock" which applies to all
> queries. This would leave our code pure-JDO (not
> DataNucleus-dependent), but it's unfortunately not what we need: Most of the
> time a lock is not required and this option would therefore
> unnecessarily slow down our application.
> 2) The page
> JDOQL<http://www.datanucleus.org/products/accessplatform/rdbms/jdoql.html>
> shows this code snippet:
> ((org.datanucleus.jdo.JDOTransaction)pm.currentTransaction()).setOption(
> "transaction.serializeReadObjects", "true"
> );
> This applies to all subsequent queries of one transaction. It works fine to
> enable/disable the option back and forth during the same transaction.
> Obviously, this is the most useful way to control the use of write-locks
> during read operations.
> 3) Additionally, the same page mentions that you can set
> "datanucleus.rdbms.query.useUpdateLock" as a JDOQL extension. I assume
> that's simply code like this:
> query.addExtension("datanucleus.rdbms.query.useUpdateLock", "true");
> In contrast to solution (2), this only affects the single explicit query and
> no implicit queries which are used when accessing fields of the returned
> object(s).
> Having explained all this, I'd like to request the following feature for the
> next JDO release (2.3):
> Please extend javax.jdo.Transaction and add 2 methods:
> void setSerializeReadObjects(boolean)
> boolean isSerializeReadObjects()
> This would make DataNucleus' solution (2) - see above - available via the JDO
> API.
> Additionally, please extend javax.jdo.Query and add 2 new method:
> void setSerializeReadObjects(boolean)
> boolean isSerializeReadObjects()
> This represents JDO-API for DataNucleus' solution (3) - see above.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
