Re: Native JDBC Limitations

["David Morris" <David.Morris@xxxxxxxxxxxxx>]

Natives,

I received a response to this question on the Toolbox Forum
pointing me to the Toolbox FAQ. I re(mis?)memeber another
restriction related to profiles. This was in a readme somewhere
and as I recall in a numbered list it said something about the
profile used for the connection had to match the profile for
the underlying job. I interpreted that to mean that in my case
the profile that starts Tomcat has to be used to get connections.

I also believe that I can swap profiles in a running thread. The
goal would be to use a generic connection pool, get a connection,
swap profiles and perform do something (most likely an update).
Then swap the profile back.

Before I start down this path, I am trying to identify any roadblocks.

The main goal is to use a real profile for updates. A secondary
goal is performance (reuse of connections). Any examples of
code that uses a profile handle or credential to swap profiles
would also be helpful. Hopefully I can do this effectively without
holding on to connections for an extended period.

David Morris

>>> David.Morris@plumcreek.com 12/18/01 11:59AM >>>
Group,

A while back I read in a FAQ or something that lists the limitations
related to running SQL directly. I am not sure, but I believe this is
referred to as non SQL server mode. One limitation I remember was that
the JDBC job and connection had to be the same profile. Can anyone
point
me to that document or something else that clearly spells out what you
can get away with? I remember another limitation listed was V5R1 is
required because JTOpen 2.05 was a V5R1 release.

I am looking at changing our servlet connection pooling, which
currently has a connection pool per user session. That is somewhat
inefficient on the AS/400 so I was hoping to be able to swap
profiles/group profiles and use a single pool. Goals would be to
identify individual users and use direct access.

David Morris