[
https://issues.apache.org/jira/browse/JDO-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12713724#action_12713724
]
Marco commented on JDO-619:
---------------------------
Adding an optional boolean parameter to pm.getObjectById(...) IMHO has the
downside that already quite a few overloaded getObjectById(...) methods exist,
where one of them already has a boolean parameter:
a) getObjectById(java.lang.Class cls, java.lang.Object key)
b) getObjectById(java.lang.Object oid)
c) getObjectById(java.lang.Object oid, boolean validate)
There's the question, to which of these getObjectById-methods do you want to
add it? Adding it as last parameter is obviously only possible for (a) and (c)
leading to 2 new methods. Alternatively you could add it at as first parameter
and then have 3 new methods.
Is that helpful? Or confusing?
Any other opinions?
The PM.serializeRead(Object) is IMHO a really good idea. If I understand you
correctly, that's more or less the same as writing:
myTransaction.setSerializeRead(true);
pm.refresh(myPersistenceCapable);
myTransaction.setSerializeRead(null);
Right? Probably the only difference is that the above code might overwrite any
previously set value (that's why we encapsulate the
Transaction.setSerializeRead(...) calls and employ reference counting - we're
using code like the above quite often).
When you add pm.serializeRead(Object), you'd need additionally
pm.serializeReadAll(Collection) to be somehow symmetric with all other methods
(detach/detachAll, refresh/refreshAll etc.) and to give the JDO implementation
the ability for optimization.
> 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: api2, specification, tck2
> Reporter: Marco
> Fix For: JDO 2 maintenance release 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.
