January 2008 - jboss-jira - Jboss List Archives

[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

18 years, 7 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-932) Implicit lock ownership check in UnversionedNode

by Manik Surtani (JIRA)

Implicit lock ownership check in UnversionedNode ------------------------------------------------ Key: JBCACHE-932 URL: http://jira.jboss.com/jira/browse/JBCACHE-932 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.ALPHA2 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.0.0.BETA2 This will involve read and write DIRECT methods on UnversionedNode to check whether the calling thread has acquired the necessary locks, else throw a lock exception. This will ensure proper concurrent access to the Node, even when not going through the interceptor stack. -- 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

18 years, 7 months

2
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1129) Specify version dependencies in component-info.xml

by Brian Stansberry (JIRA)

Specify version dependencies in component-info.xml -------------------------------------------------- Key: JBCACHE-1129 URL: http://jira.jboss.com/jira/browse/JBCACHE-1129 Project: JBoss Cache Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: 2.0.0.GA Seems they are listed in pom.xml; need equivalent entries in component-info.xml. This adds fun, since we need to ensure consistency with the AS versions. -- 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

18 years, 7 months

2
6
0 / 0

[JBoss JIRA] Created: (JBCACHE-1152) Lock acquisition and replication timeouts should use different Exception classes

by Manik Surtani (JIRA)

Lock acquisition and replication timeouts should use different Exception classes -------------------------------------------------------------------------------- Key: JBCACHE-1152 URL: http://jira.jboss.com/jira/browse/JBCACHE-1152 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.1.0.GA At the moment they both throw o.j.c.lock.TimeoutException which can be misleading -- 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

18 years, 7 months

1
5
0 / 0

[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

18 years, 7 months

3
14
0 / 0

[JBoss JIRA] Created: (JBFORUMS-259) Actions in admin panel no longer work

by Ryszard Kozmik (JIRA)

Actions in admin panel no longer work ------------------------------------- Key: JBFORUMS-259 URL: http://jira.jboss.com/jira/browse/JBFORUMS-259 Project: JBoss Forums Issue Type: Bug Components: Forum View Layer Reporter: Ryszard Kozmik Assigned To: Ryszard Kozmik Fix For: 1.0.1 RC, 1.1.0 Alpha Something caused that all actions in admin panel don't work. Additionally, some of jsf actions should be moved to jsf events to make the code look and work better. -- 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

18 years, 7 months

1
1
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-62) Slicing Replication

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-62?page=all ] Manik Surtani resolved JBCACHE-62. ---------------------------------- Fix Version/s: (was: 2.1.0.GA) Resolution: Done > Slicing Replication > ------------------- > > Key: JBCACHE-62 > URL: http://jira.jboss.com/jira/browse/JBCACHE-62 > Project: JBoss Cache > Issue Type: Feature Request > Reporter: Bela Ban > Assigned To: Manik Surtani > Original Estimate: 10 weeks > Remaining Estimate: 10 weeks > > - Replicate parts of JBossCache to different cluster nodes -- 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

18 years, 7 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBCACHE-62) Slicing Replication

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-62?page=all ] Manik Surtani reopened JBCACHE-62: ---------------------------------- Assignee: Manik Surtani (was: Bela Ban) > Slicing Replication > ------------------- > > Key: JBCACHE-62 > URL: http://jira.jboss.com/jira/browse/JBCACHE-62 > Project: JBoss Cache > Issue Type: Feature Request > Reporter: Bela Ban > Assigned To: Manik Surtani > Original Estimate: 10 weeks > Remaining Estimate: 10 weeks > > - Replicate parts of JBossCache to different cluster nodes -- 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

18 years, 7 months

1
0
0 / 0

[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

18 years, 7 months

4
20
0 / 0

[JBoss JIRA] Created: (JBRULES-1375) remove backdated concurrency classes, now that we are jdk1.5+

by Mark Proctor (JIRA)

remove backdated concurrency classes, now that we are jdk1.5+ ------------------------------------------------------------- Key: JBRULES-1375 URL: http://jira.jboss.com/jira/browse/JBRULES-1375 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Reteoo Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 4.0.4 -- 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

18 years, 7 months

1
4
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2008