[ http://issues.apache.org/jira/browse/IBATIS-233?page=all ]
Jason Erickson updated IBATIS-233:
----------------------------------
Attachment: iBATIS Bug.zip
I have attached a zip file with an Eclipse project with fairly minimal code to
reproduce the bug. It contains all the jar files necessary to run it.
There are three classes with main methods.
* InitData initializes the database. An initialized database is included,
though, so it shouldn't be necessary.)
* BugExample reproduces the bug.
* WorkingExample does the same thing as BugExample, but with the workaround.
The key methods for this bug are in ExampleSqlMapDao.testFails() and
Salesman.getRegionCodeList()
> If parameter bean does a query in property reader, causes premature return to
> connection pool
> ---------------------------------------------------------------------------------------------
>
> Key: IBATIS-233
> URL: http://issues.apache.org/jira/browse/IBATIS-233
> Project: iBatis for Java
> Type: Bug
> Versions: 2.1.5
> Environment: OS: Windows XP, Windows 2000
> JDK: 1.3.1, 1.4.2
> DBMS: SQL Server 2000, Derby
> Application Server: Weblogic 6.1 SP4
> Reporter: Jason Erickson
> Attachments: iBATIS Bug.zip
>
> If you have a bean with a getter that makes an iBATIS call, and you use that
> bean as a parameter bean in another iBATIS call, iBATIS calls the getter
> while preparing the main statement which prepares another statement to
> populate the getter. After that, the connection is returned to the pool.
> Then the main prepared statement is executed and a SQLException is thrown.
> The message depends on the driver, but jtds error message is, "Error
> accessing SimplePooledConnection. Connection has been invalidated (probably
> released back to the pool)." When using the Weblogic application server for
> connection pool, the error message is, "Connection has already been closed."
> The workaround is to put a transaction around the main call, but it can be
> quite difficult to know in advance if this will be a problem. (In our
> particular case, we had a rather expensive query called inside a cache
> object. Then we had a getter call the cache, so this only occurred when this
> query was the next query called after the cache had been marked "dirty" so
> the next call to it would reinitialize it (i.e. make another iBATIS call).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
