Question to Steve - connection names

Question

Currently we are looking for a way to give concurrency control in a XSQL application to our users.
Our Scenario is (in 2 browser sessions):
User A : select * from xy where key = 'ABC' for update
User B : select * from xy where key = 'ABC' for update
Our test results are:
User A: connection="conn1" (scott/tiger@localhost:1521:ORCL)
User B: same connection name as User A
-> no error (probably because it's the same transaction?)
User A: connection="conn1" (scott/tiger@localhost:1521:ORCL)
User B: connection="conn2" (scott/tiger@localhost:1521:ORCL)
-> error as wanted
(By the way: this behaviour changed from XSQL 1.0.3.0 to XSQL 1.0.4.3. If autocommit=true we get an error "fetch from an already closed cursor". So we have to set autocommit=false here.)
Our plan is to define 50 or more named connections in XSQLConfig.cml pointing to the same database and the same oracle user.
The pre-login page will use one standard connection. After successful authenticating the user we do a "Select for update" on a table which contains the 50 connections names, too, and connect the user in all future pages with his own "connection".
Are we far out with this approach ?
Or can we reach the same result easier ?
Thank you for your help.
Andreas
null

Answer 1

<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by Andreas Saake ([email protected]):
We want to implement in this way a successor for our client/server-based legacy application. It will run only in intranets, but many users work over ISDN lines.
Today we use MS Terminal Servers to achieve the accessibility.
The XSQL servlet is our choice because of
the very well-design structure, best integration capabilites via Java (if neccessary), the content rich HTML pages and the capability to do our business logic in the well known PL/SQL.
A detail case: A user opens an item record and wants to edit it. Other users shall not have the right to do similar work on the same item.
Without this technique we see lost update problems if not impelementing a manual timestamp access mechanism.
In the described case we know the maximal number of users for our application, so we could implement enough database connection names.
Would you propose another way for this application intention ?
Andreas<HR></BLOCKQUOTE>
You could use the newest version of DB Prism which uses JDBC 2.0 extended API to manage transaction by URL demarcation.
This new functionality use the same physical connection but independent transaction over JTA specification.
Look at this demo on-line, if you open a new browser with the link opened session/transaction you could see that same connection reuses scott's connection but open a new branch transaction.
This transaction support by url demarcation works as OAS transaction support.
Best regards, Marcelo.