Kris Jurka wrote:
>
> On Mon, 25 Oct 2004, Oliver Jowett wrote:
>
>
>>Sounds like that is (another) bug .. it should be using the
>>QUERY_SUPPRESS_BEGIN flag for driver-generated queries to avoid starting
>>a transaction accidentally. I fixed that in various other places but
>>didn't think to check the LO code.
>
>
> This might be a little tricky as the large object code uses just the
> public java.sql.* api. This situation is somewhat analogous to the
> DatabaseMetaData calls that we decided should start transactions. In any
> case I'm not sure it really matters. The only time the largeobject api
> is initialized when a query won't immediately follow is if they are using
> the LargeObjectManeger directly and not through the compatible=7.1 or
> getBlob.
I'm not entirely convinced.
The DBMD queries are a direct result of an application call. It's
reasonable to expect transactional isolation of metadata since you might
be executing DDL that affects that metadata. We don't cache the results.
In contrast, the LO stuff is one-off lazy initialization that is a
side-effect of using the LO interface for the first time. The results
are cached. We don't care about transactional isolation of the queries
(or cache invalidation) as we are not expecting the LO function
definitions to change under us. It seems like the same scenario as when
we are filling the datatype<->OID caches in the main driver.
That said, as you say it only makes a difference if you're using the LO
manager directly, so maybe this isn't so important.
-O
