[ https://issues.apache.org/jira/browse/JDO-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702463#action_12702463 ]
Andy Jefferson 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 ;-) Re: Dec 12 comments, 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. Fetch Plans : What is read FOR UPDATE ? I'd assume all objects read in the query itself would take the serialize setting as per the priority order (below). So if the query fires off 2 SELECTs one for candidate and one for related objects then * the candidate will use FOR UPDATE as per query, and if not set then txn, and if not set then metadata * the related will use FOR UPDATE as per query, and if not set then txn, and if not set then metadata. 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). > 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.