ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From iba...@rpkb.com
Subject iBatis with JNDI and WebSphere and MS-SQL Server
Date Tue, 08 Nov 2005 00:12:36 GMT

I'm having a really odd problem that I would greatly appreciate help with.  My
company is trying to use JNDI with WebSphere targeting MS-SQL Server.  In
short, when the web session times out, a read to an authentication database
causes that database to be locked to such an extent that no other sessions,
users, or clients can even do a read on those database tables.  Due to the
trace log messages, IBM is convinced that 'my' code is not closing the database
connections, and says that I should correct my code.  Well, I'm using iBatis,
and it's pretty clear to me after looking at the source that those connections
should be closing.  IBM has suggested a work-around which will cause
uncommitted transactions to commit rather than rollback.  I have managed to
convince them, I think, that a rollback should not do what it is doing
regardless of my actions.  This may ‘fix‘ my problem, but they remain adamant
that I am not properly closing my database connections and that I should
correct my code.

Below are some of the specific, but condensed, details about what I am trying to
do.  As I have been working with IBM on a PMR for about 10 weeks, copious
details are also available upon request including a sample war file and trace
logs from WebSphere.

•	Target production server is WebSphere on iSeries, but problem was
found on WS5.1.1.4 for Windows
•	User authentication is through Windows domain
•	Group has been using iBatis for approximately 2 years now
•	MS-SQL Server 2000
•	Application is ‘intranet’ only

•	First, Java web application forwards to a specifically created MS-IIS
application.  The Windows user name is then written to a ‘GateKeeper’ database
using the jsession id as the key.  IIS application then forwards back to the
java web application. (That way, no security information is passed directly
back to the java web application.)
•	Java web application reads the security information associated with the user
based upon the jsession id.  Security string (xml) is stored in the session
•	User may then perform queries against the ‘pubs’ database.  (MS-SQL standard
testing database, deployed by default with every MS-SQL server.)
•	When the web session times out, if a user attempts to perform another query,
they are forwarded to a notification page.  The user may then click to be
re-authenticated, and it all starts over again.

Problem details:
•	If the web session times out, and the user clicks to follow the link to
re-authenticate, then the database tables are locked.  This is very
duplicatable; it happens every single time.
•	Locks are for the entire table, and prevent any query action whatsoever
•	Problem has been on WebSphere and WebSphere on Windows.
•	Problem occurs with both MS JDBC drivers and WebSphere embedded drivers
•	Problem only occurs using JNDI.
•	Using JDBC with iBatis without JNDI does not exhibit any problems.
•	Problem will only occur if read of pubs database occurs
•	“Kill spid” command from SQL Server will terminate the connection and free all
users.  Otherwise, only stopping the entire server will kill the connection.
•	In trace log, IBM notes the following:  WebAppTransac E WTRN0043I:
LocalTransaction rolled-back due to setRollbackOnly    IBM has a tech note at
http://www-1.ibm.com/support/docview.wss?uid=swg21141640  which they contend
will fix the problem.  Unfortunately, it will also cause an automatic commit of
a transaction, if the developer was careless and an exception occurs.
•	No other exceptions or anomalous events occur

•	Under what circumstances will iBatis not ‘close’ database connections, i.e.,
return them to the pool?
•	Am I missing something that I need to do in iBatis that wasn’t required when
not using JNDI?
•	How do I set up logging for iBatis under WebSphere?  Can this be done as part
of the trace file so that it is all packaged together?

Thanks in advance for anyone who has the patience and time to look at this.  I
realize that this is rather lengthy, but I also realize that it may not be
nearly enough information to determine what is actually going on.


View raw message