Re: Duplicate entry issue with multithreaded application

[garpinc <ga...@yahoo.com>]

This problem is similar to this one resolved over at IBM.
http://www-01.ibm.com/support/docview.wss?uid=swg1PK60510

in my case the pk is generated but it's unique key is the same so in this
case it should ignore and do an update instead...

Rick you around yet?



--
View this message in context: http://openjpa.208410.n2.nabble.com/Duplicate-entry-issue-with-multithreaded-application-tp7580917p7581155.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: Duplicate entry issue with multithreaded application

[Rick Curtis <cu...@gmail.com>]

Is this something that you could put into a UT to easily recreate?

On Wed, Sep 26, 2012 at 10:47 AM, garpinc <ga...@yahoo.com> wrote:

> Thanks Rick...
>
>
>
>
>


-- 
*Rick Curtis*

Re: Duplicate entry issue with multithreaded application

[garpinc <ga...@yahoo.com>]

Thanks Rick...



--
View this message in context: http://openjpa.208410.n2.nabble.com/Duplicate-entry-issue-with-multithreaded-application-tp7580917p7581224.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: Duplicate entry issue with multithreaded application

[Rick Curtis <cu...@gmail.com>]

I will try to look tomorrow
On Sep 25, 2012 3:32 PM, "garpinc" <ga...@yahoo.com> wrote:

> anyone have any ideas on this?
>
>
>
> --
> View this message in context:
> http://openjpa.208410.n2.nabble.com/Duplicate-entry-issue-with-multithreaded-application-tp7580917p7581211.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Re: Duplicate entry issue with multithreaded application

[garpinc <ga...@yahoo.com>]

anyone have any ideas on this?



--
View this message in context: http://openjpa.208410.n2.nabble.com/Duplicate-entry-issue-with-multithreaded-application-tp7580917p7581211.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: Duplicate entry issue with multithreaded application

[garpinc <ga...@yahoo.com>]

Hey Rick.. Any info on this for today?



--
View this message in context: http://openjpa.208410.n2.nabble.com/Duplicate-entry-issue-with-multithreaded-application-tp7580917p7581196.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: Duplicate entry issue with multithreaded application

[garpinc <ga...@yahoo.com>]

The problem occurs because the process is running in parallel (with unique
entity managers per thread) for performance reasons and may encounter the
same row because of interrelated data.

The reason i'm marking the fields as dirty is because the jpa object is a
wrapper around another object which contains the actual data. When that
wrappee is assigned then in order for the wrapper to know that the fields
have to be marked dirty

Where can you catch the PersistenceException? The exception occurs in the
commit where many interactions with the database are occurring. I don't want
to catch the exception around the commit. I want to catch it around the
individual statement.



--
View this message in context: http://openjpa.208410.n2.nabble.com/Duplicate-entry-issue-with-multithreaded-application-tp7580917p7581193.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: Duplicate entry issue with multithreaded application

[Rick Curtis <cu...@gmail.com>]

I'm pretty busy so I'll try to help where I can.

> Is there any facility to control what happens in JPA when a unique key
constraint is violated?
No, you can catch the PersistenceException and handle the rollback
accordingly.

What isn't clear to be is why this is happening. Does this exception only
happen on the first request, then it works fine on all subsequent requests?

I noticed that you're calling directly into OpenJPA APIs to mark fields
dirty[1]... that smells a bit odd to me. I don't know if it is related to
the issue you're emailing here, but it seems a bit odd...



[1]  com.cambridgesemantics.anzo.relationalreplicator.openjpa.OpenJPAHelper.
markFieldsAsDirty(OpenJPAHelper.java:110)

On Mon, Sep 24, 2012 at 10:01 AM, garpinc <ga...@yahoo.com> wrote:

> This is my last major issue which I hope to resolve today.. Is there any
> facility to control what happens in JPA when a unique key constraint is
> violated? Rather than have the whole transaction rollback I'd just like it
> to get the existing record instead and move on...
>
> Rick any ideas here?
>
>
>


-- 
*Rick Curtis*

Re: Duplicate entry issue with multithreaded application

[garpinc <ga...@yahoo.com>]

This is my last major issue which I hope to resolve today.. Is there any
facility to control what happens in JPA when a unique key constraint is
violated? Rather than have the whole transaction rollback I'd just like it
to get the existing record instead and move on...

Rick any ideas here?



--
View this message in context: http://openjpa.208410.n2.nabble.com/Duplicate-entry-issue-with-multithreaded-application-tp7580917p7581188.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.