Hi there,
Or app has an isolated module that serves data that usually don´t
change. When we alter some rows at BD we call a method that is supposed to
flush all caches.
This is our flush code:
public void invalidaCacheNegocio() {
log.info("Invalidando caché de negocio...");
DaoManager daoManager = DaoConfig.getDaoManager();
LiteralCacheDao dao = (LiteralCacheDao)
daoManager.getDao(LiteralNegCacheDao.class);
// un DaoTransaction es un wrapper de un SQLMapClient
// creemos que solo hay un sqlmapclient para todo
SqlMapDaoTransaction sqlMapDaoTransaction =
(SqlMapDaoTransaction) daoManager.getTransaction((Dao)dao);
// flush de todas las cachés
sqlMapDaoTransaction.getSqlMap().flushDataCache();
log.info("caché de negocio invalidada");
}
It runs into an Session bean with containter managed transaction.
iBatis is configured to use EXTERNAL transaction manager.
Usually this method works fine but some days ago we have had some
errors. A dump analysis has revealed some interesting info:
[EMAIL PROTECTED]/31C2EB20
Waiters....... 33
Thread information:
Thread type..................... Servlet handler
name............................ SoapConnectorThreadPool : 1257
thread id....................... 0x5D3CCBA0
priority........................ 5
state........................... CW
Waiting on monitor................ [EMAIL PROTECTED]/31C2EB20
Waiting for web work............. no
Executing web or local EJB work.. no
Waiting for remote orb work...... no
Stack:
java.lang.Object.wait in null native=true
java.lang.Object.wait in Object.java native=false
com.ibatis.common.util.Throttle.increment in Throttle.java
native=false
com.ibatis.common.util.ThrottledPool.pop in ThrottledPool.java
native=false
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.popSession in
SqlMapExecutorDelegate.java native=false
com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.<init> in
SqlMapSessionImpl.java native=false
com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.getLocalSqlMapSession in
SqlMapClientImpl.java native=false
com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.startTransaction in
SqlMapClientImpl.java native=false
com.ibatis.dao.engine.transaction.sqlmap.SqlMapDaoTransaction.<init> in
SqlMapDaoTransaction.java native=false
com.ibatis.dao.engine.transaction.sqlmap.SqlMapDaoTransactionManager.startTr
ansaction in SqlMapDaoTransactionManager.java native=false
com.ibatis.dao.engine.impl.DaoContext.startTransaction in
DaoContext.java native=false
com.ibatis.dao.engine.impl.DaoContext.getTransaction in
DaoContext.java native=false
com.ibatis.dao.engine.impl.StandardDaoManager.getTransaction in
StandardDaoManager.java native=false
com.iberdrola.sic.seguridad.dominio.accion.FrameworkApp.invalidaCacheTecnica
in FrameworkApp.java native=false
com.iberdrola.sic.seguridad.dominio.accion.ServiciosNatImpl.invalidaCacheTec
nica in ServiciosNatImpl.java native=false
Notice that there are 33 threads bloqued on ThrottledPool!
This problem is reported as a bug on 2.1.7 version:
http://www.mail-archive.com/[email protected]/msg00939.html
But it's too late for us to go a version up, and don´t want to use
not-GA versions so I would like to solve this on 2.1.7 maybe changing our
code.
I think there are two possibilities:
- First: Include a dummy SQL sentence with a flushOnExecute. This is
a problem because we have lot of sqlmap xml files.
- Second: Add this sentence to the cache-flush code:
sqlMapDaoTransaction.commit();
Here I need your opinion because I have a very poor
knowledge about iBatis internals. Does this sence make sense in our case?
Could it resolver the ThrottledPool deadlock?
BTW, will this problem be fixed on 2.1.7 version?
Thanks!!
===============================================================
Este mensaje se dirige exclusivamente a su destinatario. La información
incluida en el
presente correo es confidencial sometida a secreto profesional, especialmente
en lo que
respecta a los datos personales, cuya divulgación está prohibida, en virtud de
la
legislación vigente. Si usted no lo es y lo ha recibido por error o tiene
conocimiento
del mismo por cualquier motivo, le rogamos que nos lo comunique por este medio
y proceda
a destruirlo o borrarlo, y que en todo caso se abstenga de utilizar,
reproducir, alterar,
archivar o comunicar a terceros el presente mensaje y ficheros anexos, todo
ello bajo
pena de incurrir en responsabilidades legales. Cualquier opinión contenida en
este correo
es exclusiva de su autor y no representa necesariamente la opinión de
Iberdrola. El
emisor no garantiza la integridad, rapidez o seguridad del presente correo, ni
se
responsabiliza de posibles perjuicios derivados de la captura, incorporaciones
de virus o
cualesquiera otras manipulaciones efectuadas por terceros.
This message is intended for the exclusive attention of the addressee(s)
indicated. Any
information contained herein is strictly confidential and privileged,
especially as
regards personal data, which must not be disclosed, in accordance with
legislation
currently in force. If you are not the intended recipient and have received it
by mistake
or learn about it in any other way, please notify us by return e-mail and
delete this
message from your computer system. Any unauthorised use, reproduction,
alteration, filing
or sending of this message and/or any attached files to third parties may lead
to legal
proceedings being taken. Any opinion expressed herein is solely that of the
author(s) and
does not necessarily represent the opinion of Iberdrola. The sender does not
guarantee
the integrity, speed or safety of this message, not accept responsibility for
any
possible damage arising from the interception, incorporation of virus or any
other
manipulation carried out by third parties.
===============================================================
Problem when flushing caches by code on version 2.1.7
Macarron Miegemolle, Eduardo Thu, 30 Nov 2006 09:00:57 -0800
- Problem when flushing caches by code on versi... Macarron Miegemolle, Eduardo
- Re: Problem when flushing caches by code... Brandon Goodin
- RE: Problem when flushing caches by code... Macarron Miegemolle, Eduardo
