SQLJ - DefaultContext Synchornization

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Almund Sebi

    SQLJ - DefaultContext Synchornization

    Hello

    I have just found this advice on the net:


    I'm interested mainly in page 19:
    [color=blue]
    > 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(Co nnectionContext .KEEP_CONNECTIO N);[/color]

    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:
    [color=blue]
    > ConnectionConte xt context = DefaultContext. getDefaultConte xt();
    > Connection con = context.getConn ection();
    > #sql{ static sql here};[/color]

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

    If I change my code to use an explicit context, the call to
    sqlj.runtime.re f.DefaultContex t.getDefaultCon text(); isn't made
    anymore, but the rest of the code stays the same (and also the
    synchronized codeblock for the ExecutionContex t).

    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

    #2
    Re: SQLJ - DefaultContext Synchornization

    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:[color=blue]
    > 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:
    >
    >[color=green]
    >>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( ConnectionConte xt.KEEP_CONNECT ION);[/color]
    >
    >
    > 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:
    >
    >[color=green]
    >>ConnectionCon text context = DefaultContext. getDefaultConte xt();
    >>Connection con = context.getConn ection();
    >>#sql{ static sql here};[/color]
    >
    >
    > Looking at the precompiler output, I see that the operations on the
    > ExecutionContex t are in a synchronized codeblock.
    >
    > If I change my code to use an explicit context, the call to
    > sqlj.runtime.re f.DefaultContex t.getDefaultCon text(); isn't made
    > anymore, but the rest of the code stays the same (and also the
    > synchronized codeblock for the ExecutionContex t).
    >
    > 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.[/color]

    Comment

    • Almund Sebi

      #3
      Re: SQLJ - DefaultContext Synchornization

      Sean McKeough <mckeough@nospa m.ca.ibm.com> wrote in message news:<boavh6$pc g$1@hanover.tor olab.ibm.com>.. .[color=blue]
      > 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.[/color]

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

      Comment

      Working...