[
https://issues.apache.org/jira/browse/JDO-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14046131#comment-14046131
]
Craig L Russell commented on JDO-589:
-------------------------------------
Here is a proposal for handling both semantics.
Users could choose either NontransactionalWrite, Autocommit, or neither.
With NontransactionalWrite true: makePersistent and deletePersistent outside of
a transaction would mark the objects as dirty and they would be committed in a
subsequent transaction.
With Autocommit true: makePersistent would start a transaction, implement the
persistence by reachability algorithm, and commit the transaction; similarly
deletePersistent would start a transaction, delete the object, and commit the
transaction.
With neither true: current behavior.
With both true: throw an exception when one of the flags is set while the other
is set.
> Allow makePersistent 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.2#6252)
