|
| Re: [Teneo] Multi thread commit and unique annotation [message #421096 is a reply to message #421095] |
Wed, 23 July 2008 21:17   |
 Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi François,
Hmm, I am not sure if there is another way than a unique constraint.
You could work with an in-memory shared list of last created names for the last period or so (maybe
not the nicest solution, but trying to think out of the box here...), which is checked when a new
name is created for an object.
Have you tried flushing the session earlier than the commit?
What do you mean with unique=true on 0-to-many, wouldn't this one also throw a lowlevel
sql/hibernate exception?
gr. Martin
François M. wrote:
> Hi,
>
> With Teneo, I have this situation where PersistThread 1 and
> PersistThread 2 perform batch transaction at the same time. They
> basically do:
>
> Query for object with name=x.
> if x does not exist
> create and persist object with name=x.
>
> I some occasion we end up with 2 objects X because both thread are not
> aware of each other work.
>
> To fix this issue, I added an hibernate annotation to one eattribute
> that force the unique constraint at the database level when I perform a
> commit. But I don't like the fact that I have to handle a specific
> database exception that occurs at commit time to properly handle this
> business rule.
>
> Is there a solution to this problem that would be closer to EMF? I am
> thinking Unique=true annotation on a 0-to-many efeatures for example.
>
> Regards
> François
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: [Teneo] Multi thread commit and unique annotation [message #421106 is a reply to message #421096] |
Thu, 24 July 2008 11:52 |
Francois
Messages: 17
Registered: July 2009 |
Junior Member |
|
|
Hi Martin,
I haven't tried adding setting the unique constrain the the 0-to-many EMF relation because the object I want to add
constrain on is not contained in another object's collection. But since it will throw the same kind of exception, there
is no point for me to try it. I was wondering if EMF would wrap the database exception into a business model exception.
Thank for the suggestion, an In-memory map/list shared amongst my thread would be a smart solution to prevent costly
exception at commit time.
François
Martin Taal wrote:
> Hi François,
> Hmm, I am not sure if there is another way than a unique constraint.
> You could work with an in-memory shared list of last created names for
> the last period or so (maybe not the nicest solution, but trying to
> think out of the box here...), which is checked when a new name is
> created for an object.
>
> Have you tried flushing the session earlier than the commit?
>
> What do you mean with unique=true on 0-to-many, wouldn't this one also
> throw a lowlevel sql/hibernate exception?
>
> gr. Martin
>
> François M. wrote:
>> Hi,
>>
>> With Teneo, I have this situation where PersistThread 1 and
>> PersistThread 2 perform batch transaction at the same time. They
>> basically do:
>>
>> Query for object with name=x.
>> if x does not exist
>> create and persist object with name=x.
>>
>> I some occasion we end up with 2 objects X because both thread are not
>> aware of each other work.
>>
>> To fix this issue, I added an hibernate annotation to one eattribute
>> that force the unique constraint at the database level when I perform
>> a commit. But I don't like the fact that I have to handle a specific
>> database exception that occurs at commit time to properly handle this
>> business rule.
>>
>> Is there a solution to this problem that would be closer to EMF? I am
>> thinking Unique=true annotation on a 0-to-many efeatures for example.
>>
>> Regards
>> François
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.02485 seconds
] 
Search
Help
Register
Login
Home
