[
https://issues.apache.org/jira/browse/JDO-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12656085#action_12656085
]
Craig Russell commented on JDO-619:
-----------------------------------
> One way is to specify this statically in the JDO metadata for a persistence
> capable class: e.g. add a boolean property useUpdateLock to the class
> metadata.
I agree this is a useful feature and it's good to have a standard name for the
concept. SerializeRead is a good crisp concept name, and we could use this for
metadata as well as the API:
element class, element interface attribute serialize-read for metadata
Transaction and Query: setSerializeRead and getSerializeRead for API
One issue that I see is when using fetch plans. Which objects should be read
with FOR UPDATE? Only root objects, or the entire fetch plan object graph?
Another issue is whether you can override the setting in metadata. If you have
a class Foo that in metadata has serialize-read, and your Transaction has
SerializeRead false (presumably the default) do you use serialize-read for Foo
or not? I'd say yes. How do you describe this behavior?
> 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
> Reporter: Marco
> Fix For: JDO 2 maintenance release 3
>
>
> 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.
