> Wouldn't the easiest solution be to make a select max(key) statement and
> then add 1 to get your new key?
This isn't an EJB question, it's a general concurrency issue.
What you say is true for single user exclusive access to the database.
However, processes seldom run in isolation.
High performance systems supporting concurrent access run a constant risk
that after process A reads the max value, but before it commits ++max to the
database, process B will read the database and get THE SAME max and
therefore try to use the same value for a PK. This is even more possible
with multi-processor arrangements. Not only the operation but the the whole
transaction becomes unserialisable and is therefore aborted by the database
server.
You could write lock the table for the duration, but bye-bye scalability.
> Is this possible and how would I write it?
It's entirely possible and you wouldn't write it now that you know better.
You would bite the bullet and implement another, more robust solution. For
example, you might build a servlet that queues requests for a single thread
that dispenses PK values. This assumes that all processes writing into the
table will use the dispenser.
There are other issues relating to initialisation of the dispenser, and the
need for it to dispense in multiple contexts (for different entities). With
appropriate design it can maintain contiguity using your ++max trick when it
starts a context.
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
