Hi Jorge,
While Jack is correct, I'm not sure how much that helps you, and I'm not
sure you want to get into JEE transactions at this point.
I wrote a tutorial in 2002 that, while obviously getting old, still was
true in virtually everything it explained, and actually used AS/400 DB2 in
the exercises.. Unfortunately Oracle has since taken it down. However, You
can start here:
https://docs.oracle.com/javase/tutorial/jdbc/basics/transactions.html
The primary thing on the AS/400 is: If you actually created your
database as a collection/schema rather than a standard library, you can
pretty much go straight ahead from above. If not, you will have to manually
start commitment control for transactions.
HTH,
Joe Sam
Joe Sam Shirah - www.conceptgo.com (904) 302-6870
conceptGO - Consulting/Development/Outsourcing
Java Filter Forum: www.ibm.com/developerworks/java
Just the JDBC FAQs: www.jguru.com/faq/JDBC
Going International? www.jguru.com/faq/I18N
Que Java400? www.jguru.com/faq/Java400
-----Original Message-----
From: jmoreno@xxxxxxxxxxxxxxxx
Sent: Thursday, May 21, 2015 1:17 PM
To: java400-l@xxxxxxxxxxxx
Subject: How does the Java product handle commitment control
Hello Java members
I have a question in regard to the way the Java product handles the
commitment control
every time an SQL statement is issued against the iSeries machine
I am not familiar with the *ISOLATION level properties, *DROP connection ,
.. etc
By comparison only this is what we do in the iSeries:
We issue the STRCMTCTL command and later the COMMIT command
In the iSeries we use the commands
STRCMTCTL with a lock level definition of (only one of the following)
*CHG
Every record read for update (for a file opened under commitment
control) is locked. If a record is changed, added, or deleted,
that record remains locked until the transaction is committed or
rolled back. Records that are accessed for update operations
but are released without being changed are unlocked.
*CS
Every record accessed for files opened under commitment control
is locked. A record that is read, but not changed or deleted,
is unlocked when a different record is read. Records that are
changed, added, or deleted are locked until the transaction is
committed or rolled back.
*ALL
Every record accessed for files opened under commitment control
is locked until the transaction is committed or rolled back.
And at some point in the application program we issue the COMMIT command
And that takes care of everything (providing that there was no need for a
roll back operation) for sake of simplicity
Please let me know how does the Java product handles this commitment
control scenario
and if by chance it gets to run the same command is the iSeries Machine
Thanks for your responses and feedback
Jorge A Moreno
Military Car Sales, Inc
Email: jmoreno@xxxxxxxxxxxxxxxx
This email, including its attachments, may contain information that is
confidential and may be protected by federal and/or state laws and
regulations, or other confidentiality privileges. This email, including
its attachments, may contain non-public information, therefore it is
intended to be conveyed only to the designated recipient(s). If you are
not an intended recipient, please delete this email, including its
attachments, and notify the sender. The unauthorized use, dissemination,
distribution or reproduction of this email, including its attachments, is
prohibited and may be unlawful.
midrange.com
