You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by susanne_j <su...@gmx.de> on 2013/10/14 14:24:51 UTC

Problem with the optimistic locking id after a unique constraint violation exception

Hello openjpa list,

I currently have the following problem and I'm now a bit helpless, how I
could avoid it ...

I'm using an optimistic locking id in my table and I have a
unique-constraint on this table.

If the user now maintains the fields, that all ends up in an attempt to save
the record which results in a unique-constraint violation exception (with an
automatic rollback), I show the exception to the user and the user has the
possibility to change the fields for the unique-constraint. I open a new
transaction and try to merge the - now detached - object with the former
uc-violation back into the new transaction-context. But now the merge call
runs into an optimistic locking exception
"Attempted to attach deleted instance type "class xxx.StGsPartner" with oid
"9".  If the instance is new, the version field should be left to its
default value."

Is the entity deleted after the unique-constraint violation excption? And do
I have to create new Instances of the object and all it's associated ones?
Or is there another way to get the object (and the associated) back into the
transaction-context?

Thanks in advance if you could help me with it!

Best regards,
Susanne.



--
View this message in context: http://openjpa.208410.n2.nabble.com/Problem-with-the-optimistic-locking-id-after-a-unique-constraint-violation-exception-tp7585160.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: Problem with the optimistic locking id after a unique constraint violation exception

Posted by susanne_j <su...@gmx.de>.
Hi openjpa-users list,

just to answer my question myself... or give some tipps...

The problem might be a problem with the openjpa-enhancement.

I tried the same procedure without the enhancement and it worked. As a
"test", I tried eclipse-link and had no problems with the same source-code
as before (using the runtime-weaving of eclipse).

As I think, the problem might have something to do with the enhanced-field
"protected transient boolean pcVersionInit;" but I haven't looked into
details...

Best regards,
Susanne.



--
View this message in context: http://openjpa.208410.n2.nabble.com/Problem-with-the-optimistic-locking-id-after-a-unique-constraint-violation-exception-tp7585160p7585166.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: Problem with the optimistic locking id after a unique constraint violation exception

Posted by susanne_j <su...@gmx.de>.
Hello Rick,

thanks for your answer!

I found a solution for my problem.

1.) detach the object from the entity-manager
2.) make a deep-copy from the entity structure
3.) open a new entity-manager
4.) merge the deep-copy into the new entity-manager
5.) do the update with try-catch and so on (and display the error to the
user in case of an exception)
6.) commit and close the new entity-manager

In case of an error, I can merge the detached object again into the former
entity-manager and have it back.
In case of a success of the update I don't need the detached object
anymore...

Seems currently to work for my needs.

Best regards,
Susanne.



--
View this message in context: http://openjpa.208410.n2.nabble.com/Problem-with-the-optimistic-locking-id-after-a-unique-constraint-violation-exception-tp7585160p7585299.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: Problem with the optimistic locking id after a unique constraint violation exception

Posted by Rick Curtis <cu...@gmail.com>.
> Is the entity deleted after the unique-constraint violation excption?

> And do I have to create new Instances of the object and all it's
associated ones?
Yes, and no. If you are quite studious, you can get a rolled back Entity
back into a 'clean' state so that you can successfully merge them back into
a persistence context (you'll need to clear out _pcVersionInit, version
fields, auto generated Id fields, and the StateManager field)... but the
easiest path might be to copy all of the data over to fresh(newly created)
Entities.


On Mon, Oct 14, 2013 at 7:24 AM, susanne_j <su...@gmx.de> wrote:

> Hello openjpa list,
>
> I currently have the following problem and I'm now a bit helpless, how I
> could avoid it ...
>
> I'm using an optimistic locking id in my table and I have a
> unique-constraint on this table.
>
> If the user now maintains the fields, that all ends up in an attempt to
> save
> the record which results in a unique-constraint violation exception (with
> an
> automatic rollback), I show the exception to the user and the user has the
> possibility to change the fields for the unique-constraint. I open a new
> transaction and try to merge the - now detached - object with the former
> uc-violation back into the new transaction-context. But now the merge call
> runs into an optimistic locking exception
> "Attempted to attach deleted instance type "class xxx.StGsPartner" with oid
> "9".  If the instance is new, the version field should be left to its
> default value."
>
> Is the entity deleted after the unique-constraint violation excption? And
> do
> I have to create new Instances of the object and all it's associated ones?
> Or is there another way to get the object (and the associated) back into
> the
> transaction-context?
>
> Thanks in advance if you could help me with it!
>
> Best regards,
> Susanne.
>
>
>
> --
> View this message in context:
> http://openjpa.208410.n2.nabble.com/Problem-with-the-optimistic-locking-id-after-a-unique-constraint-violation-exception-tp7585160.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>



-- 
*Rick Curtis*