Re: autocommit trouble with jdbc on Postgres 7.4

Okay, here's the stack trace:

java.sql.SQLException: no transaction in progress
java.sql.SQLException: ERROR: SET AUTOCOMMIT TO OFF is no longer
supported

com.servoy.j2db.persistence.RepositoryException: java.sql.SQLException:
ERROR: SET AUTOCOMMIT TO OFF is no longer supported
ERROR: SET AUTOCOMMIT TO OFF is no longer supported

What does that tell you?

On Nov 30, 2003, at 7:16 PM, Dave Tenny wrote:

> Bob Cart wrote:
>
>> On Nov 30, 2003, at 4:40 PM, Oliver Jowett wrote:
>>
>>> AFAIK the driver never generates SET AUTOCOMMIT TO OFF; the only
>>> thing it
>>> does with server-side autocommit is to turn it on if the backend
>>> defaults to
>>> off (as is possible with a 7.3 server). So I'd hazard a guess that
>>> the
>>> problematic query is actually being generated by your application
>>> code, not
>>> the JDBC driver; there's not much the driver can do about that case.
>>>
>>> Can you provide the full exception & stack trace that's generated,
>>> and
>>> ideally a statement trace from the backend?
>>>
>>> (I took a quick look at the download URL you mentioned in a later
>>> email, but
>>> it's registration-required).
>>>
>>> -O
>>
>>
>> Right. The driver for 7.4 should not even be able to generate SET
>> AUTOCOMMIT TO OFF. That's one reason why I think this is a jdbc issue
>> and not an application issue. The other reason is that the app works
>> with so many other databases - including postgres 7.3. Also, the
>> logistics of the release don't make it likely that the driver has
>> been updated for all the changes that happened late in teh
>> development cycle of pg7.4. 7.4 was just released a couple of weeks
>> ago. From looking at various threads out on the net, Tom Lane removed
>> the server side autocommit pretty recently. Now that the most recent
>> jdbc driver the 7.4 beta was posted back in september, I don't see
>> how it could have been patched up to support the autocommit change.
>> Now if you are right and the driver never was able to SET AUTOCOMMIT
>> TO OFF anyway, well we do have a tricky one. My guess is the
>> application I'm using isn't smart enough to come up with an error
>> string that says, "Error: SET AUTOCOMMIT TO OFF no longer
>> supported". That's delivered via the jdbc driver. Doesn't seem to me
>> that an app should be able to make the drive throw that even if it
>> tried.
>>
>> Some brave soul out there needs to dig into that part of the driver
>> code to see what's up. Go for it Oliver!
>
> A stacktrace is really called for first before asking some soul to
> review this. A very reasonable request.
>
> The original report said that this was third party code. Any third
> party code can have a statement.execute("SET AUTOCOMMIT OFF")
> in their library because they naively implemented their transaction
> model. And early postgres versions wouldn't have complained
> (though they might not have generated the right results!).
> I speak from experience since I was once new enough to JDBC to have
> done just this and it ran for a long time before I fixed it.
>
> So a stacktrace will clarify whether the third party code is doing
> this, or whether postgresql is doing it,
> and if so, where it's being done.
>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if
> your
> joining column's datatypes do not match
>