db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Jefferson (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JDO-589) Allow makePersistent outside a transaction
Date Wed, 18 Apr 2012 12:29:40 GMT

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

Andy Jefferson commented on JDO-589:

Presumably this means simply that the user can select if they have atomic nontransactional
writes (whether persist, delete or update) or whether they want them leaving til the next
transaction. What if they select the latter and the PM is closed? do they just get lost like
in some popular ORM?

DataNucleus provides atomic persists/deletes (not updates yet) by default, and allowing them
to go to the next transaction when enabled. When a PM is closed and there are outstanding
updates then these are committed before completing the close.
> 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
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message