[
https://issues.apache.org/jira/browse/JDO-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702485#action_12702485
]
Craig Russell commented on JDO-619:
-----------------------------------
> I took it as accepted that the methods were needed (since 2 were in favour
> and none against), and in the absence of comments on the patch applied it.
> Ooops ;-)
No problem. It's just that the patch as applied was incomplete from my
perspective.
> MetaData change makes sense, needing to go into JDO DTD/XSD (but not ORM
> DTD/XSD), as well as adding to @Persistable annotation, as well as
> ClassMetadata/InterfaceMetadata API objects. should be Boolean type
> defaulting to unspecified.
I agree.
> * the related will use FOR UPDATE as per query, and if not set then txn, and
> if not set then metadata.
The implication is that you cannot via API read FOR UPDATE *only* the root
instances of the query. The most common use case I have seen is where you use
FOR UPDATE as a guard for queried objects. For example, you use FOR UPDATE on
the Order instances and then read the related OrderLine instances without a
lock because they are guarded by the lock on the Order. But if we have the
metadata option, that might be ok.
Still, we could consider setSerializeRelatedRead(boolean related) as a separate
flag. I'd like to get others' input on this.
> Priority order for serializeRead settings ? I'd look at Query value having
> top priority, and if not set then use txn value, and if not set use metadata
> setting. Why should metadata have priority ? it is statically defined in
> annotations/XML yet the txn/query values are at runtime (dynamic).
I agree.
> 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
>
> Attachments: serialize_read.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.
