[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2532?page=c...
]
Steve Ebersole commented on HHH-2532:
-------------------------------------
Actually we can hack a workaround for 3.2. I'll add a "instanceof" style
check in here for the 3.2 series. 3.3 (and HHH-2533) will fix this in a better manner.
update/delete executeUpdate() causes problems with JBossCache (at
least in opt-locking setups)
----------------------------------------------------------------------------------------------
Key: HHH-2532
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2532
Project: Hibernate3
Issue Type: Bug
Components: query-hql, query-sql
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Fix For: 3.2.3
The underlying problem is the attempts afterwards to "clean up" the
corresponding caches. Basically we attempt a clear() from within
afterTransactionCompletion() which JBossCache's OptimisticNodeInterceptor complains
about because we are "outside a transaction". This really needs to be redone to
go through a 3-step invalidation process of the whole region, much like we do currently
for indiviudual cache items.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira