Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] @TableGenerator interaction with out-of-band apps
The script should follow the same pattern as Eclipselink's table sequencing: if it needs n ids, it should: 
begin transaction;
update my_seq = my_seq + n;
select my_seq;
commit transaction;
use n values ending with the returned value:
returned value - n + 1,..., returned value.

On 5/31/2012 5:50 PM, Laird Nelson wrote:

Hello; quick question about the implications of a third-party
application doing direct database writes while a @TableGenerator is in
effect.

We have a script that does some data conversion.  It is (I think) as
good a citizen as it can be--it reads the sequence table that we've
constructed and referred to elsewhere in our application with the
@TableGenerator annotation, and takes great care to not reuse
identifiers that have already been "claimed" by the JPA id generation
process.

But obviously it doesn't know what conceptual "block" of identifiers the
JPA provider has already reserved.  What I mean is, suppose the JPA
provider reads the sequence table in conceptual blocks of 50.  If this
script comes along and inserts a row in a table somewhere then even if
it reads the same sequence table and interprets it properly, there's
still the possibility it's going to overlap its identity assignments
with those dished out by the JPA provider.

Are there any recommendations here?

What occurred to me was to make sure that the script is at least:

   1. reading the high water mark
   2. reading the block size
   3. pessimistically locking the high water mark column then updating
      it with the new value

Am I missing anything?  Are there additional concerns I haven't thought of?

Best,
Laird

--
http://about.me/lairdnelson



_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

Back to the top