RE: no sql-select after sql-update? -- JAVA400-L

Dit is een meerdelig bericht in MIME-indeling.
--
Hmmm, seems to be a very tricky problem.  But, as I alway's say: All is
possible!

1) Application Behaviour
The difference between U2 and U3 is not another isolationlevel.  Of course
U2 could be a reader which only needs 'read-access' but not in this case!
ALL users will be using same isolationlevel!  Keep in mind that the
application does the following:
        1) U1 logs on
        2) U1 starts application
        3) U1 retrieves records he's intrested in
        4a) U1 selects a record for update
   or 4b) U1 selects a record for deletion
   or 4c) U1 wants to add a record
These action can be taken over and over by different users at the same time.
The application would be build like the ('old-fashioned'?) way of using
screens on the AS400, namely 'list-panels' and 'detail-panels':
        panel1 = detail_panel which has fields for selecting records
        panel2 = list_panel with an overview of the records
        panel3 = detail_panel with details for choosen record
One can compare this with the AS400-PDM:
        1st screen = selectionscreen (make selection)
        2nd screen = list with members (view list of members)
        3rd screen = memberdetails (edit member)

2) TransactionIsolationLevel
Again confused about the usage of Transaction settings, probably because of
the years working with RPG?  All my users need to have access for update if
they want it!  They just have to select the records and tell me what they
want to do: Update, Delete, Insert a record.  Do I have to give all users
TRANSACTION_READ_COMMITED then?  According to the books, it is not a good
idea to change transactionisolations inside 'transactions'. So, once it is
set, leave it.  In other words, don't change from T.I. RR to T.I. RC or T.I.
RU within transactions.  Because I want to use only 1 connection per user, I
thought the T.I. RR was the best option.  Only 1 connection because I want
to avoid repeatedly open and closing connections.  If I cannot have 2 users
has T.I. RR at same time:
2a) How can I know, at user logon, if this user wants to edit records or
just read them.
2b) How can I know later on, before setting T.I.RR if its done later, if
another user is already in T.I.RR updating a record.
As I understood from the books, the TRANSACTION_REPEATABLE_READ, means that
the user has extra confidence that while reading same record more than once
in his transaction, he always has the same data.  Nothing is said about
other transactions not having read-access at this time (with same T.I.RR).
Now I understand from your text, that once a user has T.I.RR and he gets a
record for update, this record is ALWAYS locked for ALL other access to this
record, including READ, when this other transaction is also in RR...
Is it save then to use TRANSACTION_READ_COMMITED for all users?  Or, maybe
it just impossible the way I want to implement this application and do I
have to review the applicationflow?

3) enviroment / your example
I work with Win2000 and VAJAVA.  I included the code into the webapp (the
logon-servlet actually) and it works exactly as I want, only that I need to
give U3 acces for update also, if U1 ends his update. Your code DOES work in
both VAJAVA and the webapp.

4)Connectioncode
Attached I'll send you the logon-servlet, connectionholder and
jdbc-connection-class.


--
[ SLogin.java of type application/octet-stream deleted ]
--
[ ConnectionHolder.java of type application/octet-stream deleted ]
--
[ CommunicateClipperJDBC.java of type application/octet-stream deleted ]
--