Re: rec i/o and commitment control in websphere

>> David,

>> I appreciate the time you have spent looking into these issues.  If you
>> would indulge me a little further, I would like you to expand on the
issue
>> regarding the toolbox:

>> Just to make sure we are both on the same wavelength, the native access
I am
>> referring to is not related to the jdbc driver.  I am referring to the
>> ability of the toolbox rec level i/o classes to access table data using
the
>> direct hooks into the lic code instead of going through the tcp/ip stack
if
>> the class is running on the local as/400.  We see a big speed
improvement
>> when the toolbox rec level i/o bypasses the tcp/ip stack in this manner.

>> Why doesnt the toolbox rec level i/o use the native access methods (as
>> defined above) when the userid of the AS/400 object and the job's userid
are
>> not the same?  Are you implying below that using the rec level native
access
>> methods instead of the tcp/ip stack requires that the work has to be
done in
>> the current users job?  This single toolbox requirement is the main
>> stumbling block keeping us from moving forward.


Thanks again for your input.  The reason the IDs must match is security.
If
the Toolbox is running under the AS/400's JVM, we assume some type of
security
validation has already been done.  Some valid profile has started the Java
program so if the AS400 object's userID matches the userID of the job,
it is safe for Toolbox to do RLA without further validation.  If the AS400
object's userID is different than the job's userID, the Toolbox assumes
the ID is not safe until some type of authentication is done.  Today that
means
switching to 'client/server' mode.  Authentication is part of handshake
between the Toolbox and the server when the Toolbox is running on the AS/40
or a non-AS/400 client, so switching to client/server mode was an easy
and safe way to carry out RLA requests.

I agree this is restrictive and we are looking for safe ways to expand
using
native APIs instead of servers when running on the AS/400.  Two obvious
options are:
   1) After authenticating via some means, swap the identity of the current
      thread so RLA activity on that thread happens under the new user
profile.

   2) After authenticating, start a second daemon job.  This job, started
      under the other user profile, would carry out RLA requests by calling
      APIs.

I sure there are more options.  Today, however, the IDs must match.


>> We are transitioning from sql to rec level i/o slowly.  For some time to
>> come we will have servlets that have a mixture of SQL and rec level i/o.
>> This works great for us now as long as the as/400 object userid is not
the
>> same as the jobs userid.  We get commitment control and life is good for
>> both the rec level code and the sql code.  The only downside is that the
>> toobox wont use the rec level i/o native access methods if the userid's
are
>> not the same.  As you can see from my benchmark posts several months
ago, we
>> really want the benefit of the native rec level access.

>> Alex Garrison

David Wall
AS/400 Toolbox for Java


+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---