Hello

I have just found this advice on the net:
http://www.share.org/proceedings/sh98/data/S1326.PDF

I'm interested mainly in page 19:

> Use explicit connection context objects
> If connection context object is omitted
> a default connection context object is used
> default connection context is not thread-safe
> can create throughput bottleneck
> Example of explicit connection context
> // Connection context declaration
> #sql context ctx;
> ...
> //get context
> myconn=new ctx(Conn1);
> ...
> //use context in SQL
> #sql [myconn] {set transaction isolation level read committed};
> ...
> #sql [myconn] cursor001 = {SELECT FKEY,FSMALLINT,FINT
> FROM WRKTB01 WHERE FKEY >= :wfkey};
> ...
> //close context but keep database connection
> myconn.close(ConnectionContext.KEEP_CONNECTION);

According to the introduction, this advice is just intended for z/OS.
But I thought it may be applicable to DB on Linux or Windows also.

Until now I have written stored procedures like this:

> ConnectionContext context = DefaultContext.getDefaultContext();
> Connection con = context.getConnection();
> #sql{ static sql here};

Looking at the precompiler output, I see that the operations on the
ExecutionContext are in a synchronized codeblock.

If I change my code to use an explicit context, the call to
sqlj.runtime.ref.DefaultContext.getDefaultContext( ); isn't made
anymore, but the rest of the code stays the same (and also the
synchronized codeblock for the ExecutionContext).

So I expect no performance gain because the synchronization overhead
is done anyway (which shouldn't be because I assume I needn't thread
safety for my explicit context object)?

Maybe anyone is able to provide further information on this subject?
Thank you.

For db2 unix/windows you MUST use an explicit context in version 8 if
you're running your sqlj routines threadsafe (this is the default for
java in v8). If you don't create an expclit context, different threads
can end up closing each others cursors etc.

Almund Sebi wrote:
> Hello
>
> I have just found this advice on the net:
> http://www.share.org/proceedings/sh98/data/S1326.PDF
>
> I'm interested mainly in page 19:
>
>
>>Use explicit connection context objects
>>If connection context object is omitted
>>a default connection context object is used
>>default connection context is not thread-safe
>>can create throughput bottleneck
>>Example of explicit connection context
>>// Connection context declaration
>>#sql context ctx;
>>...
>>//get context
>>myconn=new ctx(Conn1);
>>...
>>//use context in SQL
>>#sql [myconn] {set transaction isolation level read committed};
>>...
>>#sql [myconn] cursor001 = {SELECT FKEY,FSMALLINT,FINT
>>FROM WRKTB01 WHERE FKEY >= :wfkey};
>>...
>>//close context but keep database connection
>>myconn.close(ConnectionContext.KEEP_CONNECTION );
>
>
> According to the introduction, this advice is just intended for z/OS.
> But I thought it may be applicable to DB on Linux or Windows also.
>
> Until now I have written stored procedures like this:
>
>
>>ConnectionContext context = DefaultContext.getDefaultContext();
>>Connection con = context.getConnection();
>>#sql{ static sql here};
>
>
> Looking at the precompiler output, I see that the operations on the
> ExecutionContext are in a synchronized codeblock.
>
> If I change my code to use an explicit context, the call to
> sqlj.runtime.ref.DefaultContext.getDefaultContext( ); isn't made
> anymore, but the rest of the code stays the same (and also the
> synchronized codeblock for the ExecutionContext).
>
> So I expect no performance gain because the synchronization overhead
> is done anyway (which shouldn't be because I assume I needn't thread
> safety for my explicit context object)?
>
> Maybe anyone is able to provide further information on this subject?
> Thank you.

Sean McKeough <mckeough@nospam.ca.ibm.com> wrote in message news:<boavh6$pcg$1@hanover.torolab.ibm.com>...
> For db2 unix/windows you MUST use an explicit context in version 8 if
> you're running your sqlj routines threadsafe (this is the default for
> java in v8). If you don't create an expclit context, different threads
> can end up closing each others cursors etc.

I see. Thank you.
I'm using 7.1 currently, but maybe I'll upgrade soon.