That's interesting. I catch the opportunity to ask, is it possibly to alias/retrieve the ROWID, of the row? In SQLite that is ROWID, while reading the Java DB doc, I found no such thing and so tried to 'simulate' it with RID. However as you pointed above it doesn't alias the ROWID, which I extensively depend on.
2010/3/3, Knut Anders Hatlen <[email protected]>: > Gabriele Kahlout <[email protected]> writes: > >> Thank you for your answer. It solved it. >> >> (this is uncommitted code) >> private static Connection getConnection(final boolean autoCommit) >> throws Exception{ >> Connection con = null; >> try{ >> con = >> DriverManager.getConnection("jdbc:default:connection"); >> }catch(Exception e){ >> con = SqlWrapper.connectToDerby(); >> con.setAutoCommit(autoCommit); >> } >> return con; >> } >> >> Now, I'd like to ask the following question: >> >> Executing this, in my try-catch algorithm, this insertion throws an >> Exception. I then in the catch do things and the re-try it. However, >> different from SQLite, the RID (PRIMARY AUTOINCREMENT) is not the same >> as the previous, that failed. It seems that is wasted. >> Maybe if one rollsback the transaction it returns? But that is >> complicating in my atomic method. >> Other solutions, other than live with this extra complexity, or modify the >> algo? >> st.executeUpdate(SqlWrapper.insert(objTable, batColumn, batch)); > > Derby does not reset the auto-increment counter on failure or rollback, > as documented here[1]: > > "Derby keeps track of the last increment value for a column in a > cache. It also stores the value of what the next increment value > will be for the column on disk in the AUTOINCREMENTVALUE column of > the SYS.SYSCOLUMNS system table. Rolling back a transaction does not > undo this value, and thus rolled-back transactions can leave "gaps" > in the values automatically inserted into an identity column. Derby > behaves this way to avoid locking a row in SYS.SYSCOLUMNS for the > duration of a transaction and keeping concurrency high." > > [1] http://db.apache.org/derby/docs/10.5/ref/rrefsqlj37836.html > > If you want to avoid gaps in the identity values, perhaps you could use > GENERATED BY DEFAULT AS IDENTITY instead of GENERATED ALWAYS AS > IDENTITY, and set the RID value manually when you retry. > > -- > Knut Anders > -- Regards, K. Gabriele --- unchanged since 25/1/10 --- P.S. Unless a notification (LON), please reply either with an answer OR with " ACK" appended to this subject within 48 hours. Otherwise, I might resend. In(LON, this) ∨ In(48h, TimeNow) ∨ ∃x. In(x, MyInbox) ∧ IsAnswerTo(x, this) ∨ (In(subject(this), subject(x)) ∧ In(ACK, subject(x)) ∧ ¬IsAnswerTo(x,this)) ⇒ ¬IResend(this). Also note that correspondence may be received only from specified a priori senders, or if the subject of this email ends with a code, eg. -LICHT01X, then also from senders whose reply contains it. ∀x. In(x, MyInbox) ⇒ In(senderAddress(x), MySafeSenderList) ∨ (∃y. In(y, subject(this) ) ∧ In(y,x) ∧ isCodeLike(y, -LICHT01X) ).
