openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Petrus Viljoen (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (OPENJPA-673) Entity using Generated Value for primary key and a Version field and no DetachedStae fails to merge
Date Fri, 30 Nov 2012 19:09:59 GMT

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

Petrus Viljoen edited comment on OPENJPA-673 at 11/30/12 7:08 PM:
------------------------------------------------------------------

This issue still persists in version 2.2.1  ,  unlike  Vermeulen's comment of  25/Jan/11 14:48
 , My version field And ID is populated in the database. 
Basic flow of the cose


command  = new xxxCommand();
// ... setup instance
em.persist(Command);
em.flush(); // We must Flush to get the correct ID for the command, it is autogenerated
em.refresh(command); // We refresh for justin's sake
command.setClientTransactionID(command.generateTransactionIdentifier()); // populate the TransactionID
, THIS USES THE command's ID te generate a unique String.
... generate xml request
self.processCommandSetRequest(command,requestXml)   // In a new TransactionContext to ensure
data is commited to store
     


    @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
    public <F extends AbstractEppCommand> F processCommandSetRequest(final F command,
final String request_xml) {
        // Accessing the ID propery BEFORE the merge is ok, ID and Version is populated and
correct.
        final F command_ = eManager.merge(command);
        // Accessing the ID property After the Merge will cause the exception 
        command_.setRequestXML(request_xml);
        // IF you did not access the ID property it will now cause the exception during flush
, if you don't explicitly flush, the container gets runtime exception during transaction commit
        eManager.flush();
        eManager.detach(command_);
        return command_;
    }



[code]
Caused by: <openjpa-2.2.1-r422266:1396819 nonfatal user error> org.apache.openjpa.persistence.InvalidStateException:
Primary key field com.bluedigital.ejb.epp.DomainCheckCommand.domainCheckCommandID of com.bluedigital.ejb.epp.DomainCheckCommand@1ef5a718
has non-default value. The instance life cycle is in PNewState state and hence an existing
non-default value for the identity field is not permitted. You either need to remove the @GeneratedValue
annotation or modify the code to remove the initializer processing.
	at org.apache.openjpa.util.ApplicationIds.assign(ApplicationIds.java:489)
	at org.apache.openjpa.util.ApplicationIds.assign(ApplicationIds.java:469)
	at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.assignObjectId(JDBCStoreManager.java:762)
	at org.apache.openjpa.kernel.DelegatingStoreManager.assignObjectId(DelegatingStoreManager.java:135)
	at org.apache.openjpa.kernel.StateManagerImpl.assignObjectId(StateManagerImpl.java:600)
	at org.apache.openjpa.kernel.StateManagerImpl.assignField(StateManagerImpl.java:691)
	at org.apache.openjpa.kernel.StateManagerImpl.beforeAccessField(StateManagerImpl.java:1660)
	at org.apache.openjpa.kernel.StateManagerImpl.accessingField(StateManagerImpl.java:1591)
	at com.bluedigital.ejb.epp.DomainCheckCommand.pcGetdomainCheckCommandID(DomainCheckCommand.java)
	at com.bluedigital.ejb.epp.DomainCheckCommand.getId(DomainCheckCommand.java:53)
	at com.bluedigital.ejb.logic.RegistryTransportManager.processCommandSetRequest(RegistryTransportManager.java:677)
[code]



As an additional NOTE, This is a bit more complex than just GeneratedValue + Version,  The
exact same code works flawlessly if the entity was generated and persisted in this bean. But
when the Entity generated+persisted in StatelessBean A then passed via EJB to StatelessBean
B , this is when this merge BUG is triggered. 






                
      was (Author: viljoenp):
    This issue still persists in version 2.2.1  ,  unlike  Vermeulen's comment of  25/Jan/11
14:48  , My version field And ID is populated in the database. 
Basic flow of the cose


command  = new xxxCommand();
// ... setup instance
em.persist(Command);
em.flush(); // We must Flush to get the correct ID for the command, it is autogenerated
em.refresh(command); // We refresh for justin's sake
command.setClientTransactionID(command.generateTransactionIdentifier()); // populate the TransactionID
, THIS USES THE command's ID te generate a unique String.
... generate xml request
self.processCommandSetRequest(command,requestXml)   // In a new TransactionContext to ensure
data is commited to store
     


    @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
    public <F extends AbstractEppCommand> F processCommandSetRequest(final F command,
final String request_xml) {
        // Accessing the ID propery BEFORE the merge is ok, ID and Version is populated and
correct.
        final F command_ = eManager.merge(command);
        // Accessing the ID property After the Merge will cause the exception 
        command_.setRequestXML(request_xml);
        // IF you did not access the ID property it will now cause the exception during flush
, if you don't explicitly flush, the container gets runtime exception during transaction commit
        eManager.flush();
        eManager.detach(command_);
        return command_;
    }



[code]
Caused by: <openjpa-2.2.1-r422266:1396819 nonfatal user error> org.apache.openjpa.persistence.InvalidStateException:
Primary key field com.bluedigital.ejb.epp.DomainCheckCommand.domainCheckCommandID of com.bluedigital.ejb.epp.DomainCheckCommand@1ef5a718
has non-default value. The instance life cycle is in PNewState state and hence an existing
non-default value for the identity field is not permitted. You either need to remove the @GeneratedValue
annotation or modify the code to remove the initializer processing.
	at org.apache.openjpa.util.ApplicationIds.assign(ApplicationIds.java:489)
	at org.apache.openjpa.util.ApplicationIds.assign(ApplicationIds.java:469)
	at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.assignObjectId(JDBCStoreManager.java:762)
	at org.apache.openjpa.kernel.DelegatingStoreManager.assignObjectId(DelegatingStoreManager.java:135)
	at org.apache.openjpa.kernel.StateManagerImpl.assignObjectId(StateManagerImpl.java:600)
	at org.apache.openjpa.kernel.StateManagerImpl.assignField(StateManagerImpl.java:691)
	at org.apache.openjpa.kernel.StateManagerImpl.beforeAccessField(StateManagerImpl.java:1660)
	at org.apache.openjpa.kernel.StateManagerImpl.accessingField(StateManagerImpl.java:1591)
	at com.bluedigital.ejb.epp.DomainCheckCommand.pcGetdomainCheckCommandID(DomainCheckCommand.java)
	at com.bluedigital.ejb.epp.DomainCheckCommand.getId(DomainCheckCommand.java:53)
	at com.bluedigital.ejb.logic.RegistryTransportManager.processCommandSetRequest(RegistryTransportManager.java:677)
[code]


                  
> Entity using Generated Value for primary key and a Version field and no DetachedStae
fails to merge 
> ----------------------------------------------------------------------------------------------------
>
>                 Key: OPENJPA-673
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-673
>             Project: OpenJPA
>          Issue Type: Bug
>            Reporter: Pinaki Poddar
>
> Entities using GeneratedValue for primary key, a version field an dno detached state
fails to merge.
> The issue lies with identifying :"what makes a new instance?"
> It is not obvious why VersionAttachStrategy does not use version field to detect newness.
Instead it depends on detached state which is obviously null for instances not using a Detached
State.
> Can someone shade some light on why VersionAttachStrategy ignores version field to detect
newness? 
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message