> pStatement = con.prepareStatement(
> "Insert into Attribute " +
> "(ID, Value, Display_Format, Attribute_Switches, Name, Type_ID)
" +
> "Select max(id)+1, ?, ?, ?, ?, ? from Container ");
> Wouldn't most, if not all, databases handle concurrancy issues in this
case?
Alas, no. Inserts are queued because they are very slow (they involve index
updates on the PK). The read locks will be released long before the insert
executes in nearly all cases. This sort of thing isn't obvious until you
work on the innards of a high performance db server.
The only thing you can do to make this safe is get a table lock at the start
of your operation. Which may prove impossible if other processes have read
locks.
As a matter of interest I've been giving some thought to JBoss's methodology
for CMP updates. At the moment there are conditions where a row is deleted
and re-inserted in order to avoid dependencies on column names.
I'm not too thrilled with dependence on ordinal column position - this is
specifically forbidden by relational theory.
My religious position notwithstanding, deletion and re-insertion causes not
one but *two* index updates *per table index* and therefore, I think, it
will be a lot cheaper to create an updateable ResultSet and manipulate that
by ordinal position.
There may be other considerations. If so, I hope someone will advise before
I waste too much time on it.
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
