[jira] [Commented] (JDO-589) Allow makePersistent and deletePersistent outside a transaction

["Craig L Russell (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JDO-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14131728#comment-14131728 ] 

Craig L Russell commented on JDO-589:
-------------------------------------

I'd prefer the second option: adding a new property AutoCommit, with 
void setAutoCommit(boolean)
boolean getAutoCommit()

Autocommit true, NontransactionalWrite true 

When setting this combination, the cache must not have any dirty objects, and a transaction must not be active. Any write will immediately commit a new transaction.

Autocommit true, NontransactionalWrite false

Any write will immediately commit a new transaction.

Autocommit false, NontransactionalWrite true

Any makePersistent or deletePersistent or object modification will make the cached objects dirty and will be committed the next time the user begins and commits a transaction. This is the same behavior as today.

Autocommit false, NontransactionalWrite false

No makePersistent or deletePersistent or object modification outside a transaction.  This is the same behavior as today.


> Allow makePersistent and deletePersistent outside a transaction
> ---------------------------------------------------------------
>
>                 Key: JDO-589
>                 URL: https://issues.apache.org/jira/browse/JDO-589
>             Project: JDO
>          Issue Type: New Feature
>          Components: api, specification, tck
>    Affects Versions: JDO 2 maintenance release 1 (2.1)
>            Reporter: Craig L Russell
>             Fix For: JDO 3.2
>
>
> JPA allows users to call makePersistent outside a transaction, and then when beginning and committing a transaction, the instances are made persistent.
> This is similar to nontransactional dirty in which the managed instances can be modified outside a transaction and then the changes committed within a transaction.
> From the JPA spec, "When an EntityManager with an extended persistence context is used, the persist, remove, merge, and refresh operations may be called regardless of whether a transaction is active. The effects of these operations will be committed to the database when the extended persistence context is enlisted in a transaction and the transaction commits."
> This behavior should not be the default behavior (for backward compatibility reasons if not the principle of least surprise) so it should be under control of a PersistenceManager and PersistenceManagerFactory flag, perhaps NontransactionalNew.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)