Received: from noao.edu (root@noao.edu [140.252.1.54]) by hub.org (8.10.1/8.10.1) with ESMTP id e55FbmO45487 for ; Mon, 5 Jun 2000 11:37:48 -0400 (EDT) Received: from reynaud.tuc.noao.edu (reynaud.tuc.noao.edu [140.252.38.6]) by noao.edu (8.9.3/8.8.8/SAG-27Sep99) with ESMTP id IAA07349 for ; Mon, 5 Jun 2000 08:37:47 -0700 (MST) (envelope-from swampler@noao.edu) Received: from noao.edu by reynaud.tuc.noao.edu (8.9.1b+Sun/SMI-SVR4-SAG05) id IAA05212; Mon, 5 Jun 2000 08:37:44 -0700 (MST) Message-ID: <393BC948.43803086@noao.edu> Date: Mon, 05 Jun 2000 08:37:44 -0700 From: Steve Wampler Organization: National Solar Observatory X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: postgres-interfaces Subject: Re: JDBC squirrely transaction behavior?? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Archive-Number: 200006/26 Peter Mount wrote: > .... > > > This code will run for a number of insertions, then fail because the > > select of the foo_id returns no records. This should be impossible, > > because either (1) the foo_id was just added to the foos table, or (2) > > it had previously been added. Either way, there should be a record > > with a matching namefield. > > I can see a problem here. Your first insert inserts foo_id, and fails if > foo_id already exists. In your code, you ignore this which is fine outside > a Transaction. However, because you are using a transaction, the > transaction is now in a failed state, so everything else done in that > transaction will be ignored. Hmmm, that may cause me a problem in a similar situation - I want to do an update whenever an insert fails. Further, for performance reasons the insertions are done in large transactions (thousands to tens of thousands of inserts in each transaction). Does the above comment mean that this ("update after failed insert") won't work as I'd like because it's inside a transaction? Is there a way to force the state of the transaction back to success after the failed insert, without losing the insertions that have been made previously in the transaction [or those that are made subsequently...]? > The alternative is to but a connection.commit() after the insert, which > may work in this case, but you have to think about the integrity of your > tables. This sounds like it would work in my case - does anyone see why it wouldn't or have a more appropriate approach? (Through JDBC, of course.) Thanks! -- Steve Wampler- SOLIS Project, National Solar Observatory swampler@noao.edu