Re: problem with new autocommit config parameter and jdbc

On Tue, 10 Sep 2002, Stephan Szabo wrote:

> On Tue, 10 Sep 2002, scott.marlowe wrote:
> 
> > On Tue, 10 Sep 2002, Stephan Szabo wrote:
> >
> > > > > > > It starts a transaction, failes the first command and goes into the
> > > > > > > error has occurred in this transaction state.  Seems like reasonable
> > > > > > > behavior.
> > > > > >
> > > > > > Select command don't start transaction - it is not good
> > > > >
> > > > > I think you need more justification than "it is not good."  If I do a
> > > > > sequence of select statements in autocommit=false, I'd expect the same
> > > > > consistancy as if I'd done
> > > > > begin;
> > > > > select ...;
> > > > > select ...;
> > > > >
> > > > Ok.You start transaction explicit and this is ok.
> > > > But simple SELECT don't start transaction.
> > >
> > > Actually someone post a bit from Date's book that implies it does.
> > > And, that's still not an justification, it's just a restating of same
> > > position. I don't see any reason why the two should be different from
> > > a data consistency standpoint, there might be one, but you haven't
> > > given any reasons.
> >
> > What if it's a select for update?  IF that failed because of a timout on a
> > lock, shouldn't the transaction fail?  Or a select into?  Either of those
> > should make a transaction fail, and they're just selects.
> 
> Yes, but I think it should still work the same as if it had failed in an
> explicit transaction if autocommit is false (or was that directed at
> someone else).

Sorry, I was agreeing with you, and disagreeing with the guy who was 
saying that selects shouldn't start a transaction.  Should have mentioned 
that. :-)