[JBoss JIRA] Created: (JBCACHE-788) Optimistic locking should not REQUIRE transactions!
by Manik Surtani (JIRA)
Optimistic locking should not REQUIRE transactions!
---------------------------------------------------
Key: JBCACHE-788
URL: http://jira.jboss.com/jira/browse/JBCACHE-788
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 1.4.0, 1.3.0, 2.0.0
Reporter: Manik Surtani
Assigned To: Manik Surtani
Fix For: 2.1.0
Makes things simpler.
TXs are only used so transaction workspaces can be stored in a transaction entry. This workspace can just as easily be stored in ThreadLocal for non-tx calls (that just have the lifespan of a single invocation).
This will:
1) Make things a LOT quicker since we don't need 2PC for all calls.
2) Make the TxInterceptor a lot simpler
3) Allow the use of Opt Locking without a TM
--
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
17 years
[JBoss JIRA] Created: (JBCACHE-1166) UpgradeException on concurent put/remove operation
by Jacek Halat (JIRA)
UpgradeException on concurent put/remove operation
--------------------------------------------------
Key: JBCACHE-1166
URL: http://jira.jboss.com/jira/browse/JBCACHE-1166
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.0.0.GA
Environment: Windows XP, Sun jdk150_06
Reporter: Jacek Halat
Assigned To: Manik Surtani
Attachments: ConcurentOperationTest.java
When 2 Threads simultanous are attaching/detaching object from this same region sometimes TreeCache fails with Exception:
upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock
Full StackTrace:
org.jboss.cache.pojo.PojoCacheException: detach /a/b/c/d failed
at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java:158)
at org.jboss.cache.pojo.impl.PojoCacheDelegate.putObjectII(PojoCacheDelegate.java:143)
at org.jboss.cache.pojo.impl.PojoCacheImpl.putObject(PojoCacheImpl.java:136)
at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:101)
at org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:93)
at org.jboss.cache.aop.ConcurentOperationTest$WorkThread.run(ConcurentOperationTest.java:80)
Caused by: org.jboss.cache.lock.UpgradeException: failure upgrading lock: fqn=/__JBossInternal__/a/b/c/d/_ID_/a1170-d7nvs9-f5gejrti-1-f5gejrti-2, caller=GlobalTransaction:<10.1.1.252:4508>:19, lock=read owners=[GlobalTransaction:<10.1.1.252:4508>:18, GlobalTransaction:<10.1.1.252:4508>:19] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1)
at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:508)
at org.jboss.cache.interceptors.PessimisticLockInterceptor$LockManager.acquire(PessimisticLockInterceptor.java:579)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:393)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:329)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:187)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
at org.jboss.cache.interceptors.NotificationInterceptor.invoke(NotificationInterceptor.java:32)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:298)
at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:131)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:97)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
at org.jboss.cache.interceptors.InvocationContextInterceptor.invoke(InvocationContextInterceptor.java:62)
at org.jboss.cache.CacheImpl.invokeMethod(CacheImpl.java:3939)
at org.jboss.cache.CacheImpl.put(CacheImpl.java:1598)
at org.jboss.cache.pojo.impl.PojoCacheDelegate.removeObject(PojoCacheDelegate.java:273)
at org.jboss.cache.pojo.impl.PojoCacheImpl.removeObject(PojoCacheImpl.java:170)
at org.jboss.cache.pojo.impl.PojoCacheImpl.detach(PojoCacheImpl.java:153)
... 5 more
Caused by: org.jboss.cache.lock.UpgradeException: acquireWriteLock(): lock upgrade failed for /__JBossInternal__/a/b/c/d/_ID_/a1170-d7nvs9-f5gejrti-1-f5gejrti-2 (caller=GlobalTransaction:<10.1.1.252:4508>:19, lock info: read owners=[GlobalTransaction:<10.1.1.252:4508>:18, GlobalTransaction:<10.1.1.252:4508>:19] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=1))
at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:209)
at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:167)
at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:497)
... 25 more
Caused by: org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock
at org.jboss.cache.lock.ReadWriteLockWithUpgrade.upgradeLockAttempt(ReadWriteLockWithUpgrade.java:107)
at org.jboss.cache.lock.LockStrategyRepeatableRead.upgradeLockAttempt(LockStrategyRepeatableRead.java:43)
at org.jboss.cache.lock.IdentityLock.acquireWriteLock0(IdentityLock.java:203)
... 27 more
--
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
17 years
[JBoss JIRA] Created: (JBAS-4148) Replace Gjt code used in the ejb 2.x validation phase
by Fernando Nasser (JIRA)
Replace Gjt code used in the ejb 2.x validation phase
-----------------------------------------------------
Key: JBAS-4148
URL: http://jira.jboss.com/jira/browse/JBAS-4148
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Fernando Nasser
Fix For: JBossAS-4.2.1.CR1
The JBossAS thirdpart-build.xml grabs a
<componentref name="gjt-jpl-util" version="1.0"/>
from repository.jboss.com
However, the Gjt project has never released a 1.0 version, only a 0.6 version for the Linffors utils and the jpl_util_0_6 is the only tag in their CVS.
So, what is the meaning for version 1.0? The CVS tip?
Also, what is marked as gjt-jpl-util also contains gjt-jpl-pattern, and the latest CVS tag for that is:
jpl-pattern_0_3_b (0.3 beta perhaps)
Besides, there is a warning in the pattern source directory:
"Untagged files may be (and probably are) in an unstable state and might not
compile. If you want something that works, checkout with tags. You have been
warned. :) -- Juha"
Here, for the record, is Scott's opinion:
Scott M Stark wrote:
> This is some ancient code used only in the ejb 2.x validation phase. It
> has not been touched in something like 5 years. Either we need to
> replace it or pull together some code that makes up a usable release.
--
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
17 years