[
https://hibernate.onjira.com/browse/HHH-7193?page=com.atlassian.jira.plug...
]
Shawn Clowater commented on HHH-7193:
-------------------------------------
Made the mod and added a test, hopefully I did this correctly.
https://github.com/hibernate/hibernate-orm/pull/292
The test illustrates that in an initial transaction 2 entities are inserted but one fails
validation rolling the transaction back. However the validated entity is still staged on
the cached prepared statement and is inserted on the second transaction unless the batch
is cleared()
Transaction Rollback not clearing statement batch on Prepared
Statement causes issues with statement caching
------------------------------------------------------------------------------------------------------------
Key: HHH-7193
URL:
https://hibernate.onjira.com/browse/HHH-7193
Project: Hibernate ORM
Issue Type: Bug
Components: core
Affects Versions: 4.1.1
Environment: Hibernate 4.1.1 and before
Any connection provider that allows statement caching (i.e. C3P0)
Reporter: Shawn Clowater
The AbstractBatchImpl closes the preparedStatement in a finally block but doesn't
call clear in the event of a rollback. This can leave the preparedStatment in a weird
state if any type of statement caching is being used.
The issue is easily fixed by adding a clearBatch() call to the statement prior to close.
I was previously working around this by implementing my own BatchingBatcherFactory in Hib
3 but the API changed forcing me to look at it again. I figured I might as well provide a
global fix.
I'll add a pull request once I get github sorted.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira