db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marco (JIRA)" <j...@apache.org>
Subject [jira] Updated: (JDO-619) API required for enabling/disabling FOR UPDATE locking for SELECTs
Date Thu, 27 Nov 2008 12:50:44 GMT

     [ https://issues.apache.org/jira/browse/JDO-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Marco updated JDO-619:
----------------------

    Description: 
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.


  was:
I've 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.



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


Mime
View raw message