[JBoss JIRA] Created: (JBCACHE-767) Fail more silently when setting node versions
by Owen Taylor (JIRA)
Fail more silently when setting node versions
---------------------------------------------
Key: JBCACHE-767
URL: http://jira.jboss.com/jira/browse/JBCACHE-767
Project: JBoss Cache
Issue Type: Patch
Security Level: Public (Everyone can see)
Affects Versions: 1.4.0.SP1
Reporter: Owen Taylor
Assigned To: Manik Surtani
Priority: Minor
Attachments: jbosscache-fail-more-silently-20060912.patch
Hibernate's OptimisticTreeCache.writeUpdate does:
Option option = new Option();
option.setFailSilently( true );
option.setDataVersion( NonLockingDataVersion.INSTANCE );
cache.remove( new Fqn( regionFqn, key ), "ITEM", option );
Which you would expect would remove the item if it exists, while setting the data version,
and silently do nothing otherwise. But it ends up, logging at level INFO:
12:55:38,360 INFO [org.jboss.cache.interceptors.TxInterceptor] (http-127.0.0.1-8080-1): There was a problem handling this request
java.lang.NullPointerException
at org.jboss.cache.interceptors.OptimisticNodeInterceptor.invoke(OptimisticNodeInterceptor.java:68)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.EvictionInterceptor.invoke(EvictionInterceptor.java:84)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.OptimisticCreateIfNotExistsInterceptor.invoke(OptimisticCreateIfNotExistsInterceptor.java:69)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.invoke(OptimisticValidatorInterceptor.java:75)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:122)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.OptimisticReplicationInterceptor.invoke(OptimisticReplicationInterceptor.java:136)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:183)
at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5530)
at org.jboss.cache.TreeCache.remove(TreeCache.java:3742)
at org.jboss.cache.TreeCache.remove(TreeCache.java:3297)
at org.hibernate.cache.OptimisticTreeCache.writeLoad(OptimisticTreeCache.java:76)
There are some differences of opinion as to what should be logged at level INFO, but that's pretty clearly
too much and too scary looking. My assumption is that any NullPointerException in the logs is a serious
problem.
What the attached patch does is if the failSiliently option is set and the node doesn't exist, just skip
setting the version. If failSilenlty isn't set, then it throws a CacheException rather than the current
NullPointerException.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 7 months
[JBoss JIRA] Created: (JBESB-110) 1 tx per connection config
by Kurt Stam (JIRA)
1 tx per connection config
--------------------------
Key: JBESB-110
URL: http://jira.jboss.com/jira/browse/JBESB-110
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: ESB Core
Affects Versions: 4.0 Beta 1
Reporter: Kurt Stam
Assigned To: Mohit Keswani
Fix For: 4.0
Oracle does not allow multiple tx over 1 connection, however the JCA
spec allows this (and most open source dbs support it). So we need some setting you can turn on to block the
connection while a tx is in progress. Just for Oracle..as it will send
Oracle into a spin lock :). This is not something for beta1. So don't
sweat it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 7 months
[JBoss JIRA] Created: (JBESB-103) Refactor BobjStdDTO
by Mark Little (JIRA)
Refactor BobjStdDTO
-------------------
Key: JBESB-103
URL: http://jira.jboss.com/jira/browse/JBESB-103
Project: JBoss ESB
Issue Type: Task
Security Level: Public (Everyone can see)
Components: ESB Core
Affects Versions: 4.0 Beta 1
Reporter: Mark Little
Assigned To: Esteban Schifman
Fix For: 4.0
As well as renaming the class, how much of it needs to be seen by developers? The have to provide toXML and fromXML (via constructor), but do they need to see everything else? If there are no other methods that they need to be concerned about, can we not refactor this into an interface that has just the methods developers need and use the rest as the engine for driving implementations of that class?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 7 months