[
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.
