The reason you need a seperate context in 8.1 is that we're
multithreading on the JVM. Without a context per thread, threads would
run wild over each others objects (cursors etc) closing them, and other
bad things.

If you don't want to use CALL, you can catalog your sqlj stored
procedures as 'not threadsafe' and share the context like you used to
(use the old way of defining the null connection). (I haven't acutally
tried this, but it should work) :-).

You have to choose the tradeoff of multiple JVMs per instance (1 per
concurrently active non threadsafe Java routine) vs. changing your
routines. The change to threadedness was done for scalability.

Janick wrote:
> With DB2 7.2 we used to call methods from other SQLJ Stored
> Procedures, as it was not possible to call SPs via the SQL
> Call-statement from within SPs. So we always had a method like this:
>
> protected static void execute(Connection con, (...))
>
> Where we passed a Connection object for dynamic SQL (which we got
> using the getConnection() method of the DefaultContext). Static SQL
> was always executed on the DefaultContext.
>
> Now with DB2 8.1 we are forced to create a dedicated Context for each
> SP, and therefore changed our execute-method to something like this:
>
> protected static void execute(ConnectionContext context, Connection
> con, (...))
>
> The problem now is that the SQLJ Precompiler doesn't like the "simple"
> ConnectionContext. So if you would try something like this in the
> "execute" method
>
> #sql [context] { SELECT imbreqd FROM sysibm.sysdummy1 }
>
> the precompiler says that you have to declare ConnectionContextes
> using #sql context declaration. So I changed the execute-method to the
> following:
>
> protected static void execute(SPName_ConnectionContext context,
> Connection con, (...))
>
> This works fine for the current procedure, but I cannot call the
> method from another SP anymore.
>
> There are two solutions which come to mind:
> 1. Call one SP from another using the SQL-Call-command (now supported
> with 8.1)
> 2. Define one global ConnectionContext used by all SPs
>
> The first solution I don't like as it is much slower than calling a
> Java method directly. I'm not sure if the second solution is a
> "proper" solution, as you always operate on the same context-class and
> this may therefore not be threadsafe (I don't know how those
> context-classes are implemented).
>
> Maybe somebody can think of another (better) solution or tell me
> whether the second solution would be threadsafe or not.
>
> Regards,
> - Janick Bernet, SwissASP