April 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBCACHE-281) PojoCahce initialize "aspectized" pojos when first retrieved

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-281?page=all ] Jason T. Greene updated JBCACHE-281: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > PojoCahce initialize "aspectized" pojos when first retrieved > ------------------------------------------------------------ > > Key: JBCACHE-281 > URL: http://jira.jboss.com/jira/browse/JBCACHE-281 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Jason T. Greene > Fix For: PojoCache 2.1.0 > > Original Estimate: 3 days > Remaining Estimate: 3 days > > Currently, when we do getObject for the first time, we don't initialize the "aspectized" pojo after a get/set is requested. As a result, some of the fields will be un-initialized untill after they are accessed. > We need to provide an option to actively initialize the pojos. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-71) Resizing cache at runtime

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-71?page=all ] Jason T. Greene updated JBCACHE-71: ----------------------------------- Assignee: Jason T. Greene (was: Ben Wang) > Resizing cache at runtime > ------------------------- > > Key: JBCACHE-71 > URL: http://jira.jboss.com/jira/browse/JBCACHE-71 > Project: JBoss Cache > Issue Type: Sub-task > Reporter: Ben Wang > Assigned To: Jason T. Greene > Fix For: 2.2.0.GA > > Original Estimate: 3 days > Remaining Estimate: 3 days > > With the dynamic runtime configuration of eviction policy, we should be able to resize the cache at runtime. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-687) PojoCache to use aop 2.0 to bind interceptor dynamically

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-687?page=all ] Jason T. Greene updated JBCACHE-687: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > PojoCache to use aop 2.0 to bind interceptor dynamically > -------------------------------------------------------- > > Key: JBCACHE-687 > URL: http://jira.jboss.com/jira/browse/JBCACHE-687 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Jason T. Greene > Fix For: 2.1.0.GA > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Currently in 2.0, I am introducing new field level interceptos such as SubjectInterceptor to emit the field events. However, make "introduction" to a POJO with a Subject interface also has the side effect of the interceptor will bind to that method jointpoint as well. This is not desirable. > Workaround is to check for MehtodInvocation is each field level interceptor or in AOP2.0, we can bind specifically to the Pointcut programmtically as discussed in the forum post. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-518) Investigate use a new replication schema for PojoCache

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-518?page=all ] Jason T. Greene updated JBCACHE-518: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > Investigate use a new replication schema for PojoCache > ------------------------------------------------------ > > Key: JBCACHE-518 > URL: http://jira.jboss.com/jira/browse/JBCACHE-518 > Project: JBoss Cache > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Jason T. Greene > Fix For: PojoCache 2.2.0 > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > We should look into a new replication schema for PojoCache putObject and removeObject operation. Idea is during replication, instead of breaking it down and do lots of puts, we replicate the original objects and map it into PojoCache on the other side. This has potential of saving the binary size but has pontential to be more cpu intensive. > The other issue is what to do with automicity during putObject and removeObject? -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-466) Create api-less annotation for PojoCache

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-466?page=all ] Jason T. Greene updated JBCACHE-466: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > Create api-less annotation for PojoCache > ---------------------------------------- > > Key: JBCACHE-466 > URL: http://jira.jboss.com/jira/browse/JBCACHE-466 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Jason T. Greene > Fix For: PojoCache 2.2.0 > > Original Estimate: 4 weeks > Remaining Estimate: 4 weeks > > Use annotation to signifyas per the spec documentation: @attach, @reattach -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-467) ejb3 annotation integration

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-467?page=all ] Jason T. Greene updated JBCACHE-467: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > ejb3 annotation integration > --------------------------- > > Key: JBCACHE-467 > URL: http://jira.jboss.com/jira/browse/JBCACHE-467 > Project: JBoss Cache > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Jason T. Greene > Fix For: PojoCache 2.1.0 > > -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-413) Split up build.xml

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-413?page=all ] Jason T. Greene updated JBCACHE-413: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > Split up build.xml > ------------------ > > Key: JBCACHE-413 > URL: http://jira.jboss.com/jira/browse/JBCACHE-413 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Jason T. Greene > Priority: Minor > Fix For: 2.0.0.GA > > Original Estimate: 1 day > Remaining Estimate: 1 day > > buidl.xml is getting too big. Maybe we should split them up, e.g., split the pojo cache portion is a starter. We can do it as JbossAs with import directory. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-97) ReadWriteLockWithUpgrade: UpgradeException with more than 1 reader/writer waiting to upgrade lock

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-97?page=all ] Jason T. Greene updated JBCACHE-97: ----------------------------------- Assignee: Jason T. Greene (was: Ben Wang) > ReadWriteLockWithUpgrade: UpgradeException with more than 1 reader/writer waiting to upgrade lock > ------------------------------------------------------------------------------------------------- > > Key: JBCACHE-97 > URL: http://jira.jboss.com/jira/browse/JBCACHE-97 > Project: JBoss Cache > Issue Type: Bug > Reporter: Bela Ban > Assigned To: Jason T. Greene > Fix For: 2.1.0.GA > > > TxDeadlockUnitTestCase has 2 methods that show the following stack traces: > testMoreThanOneUpgrader: > Upgrader#0: get(/a/b/c) > Upgrader#1: get(/a/b/c) > main: locks: > /a (read owners=[<null>:2, <null>:1]) > /b (read owners=[<null>:2, <null>:1]) > /c (read owners=[<null>:2, <null>:1]) > Upgrader#0: put(/a/b/c) > Upgrader#1: put(/a/b/c) > Upgrader#1: org.jboss.cache.lock.LockingException: acquireWriteLock(): lock upgrade failed for /a/b/c (caller=<null>:2); - nested throwable: (org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock) > Upgrader#0: org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:2] > Write lock owner: null > (caller=<null>:1) > org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:2] > Write lock owner: null > (caller=<null>:1) > at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:155) > at org.jboss.cache.Node.acquireWriteLock(Node.java:448) > at org.jboss.cache.Node.acquire(Node.java:417) > at org.jboss.cache.interceptors.LockInterceptor.lock(LockInterceptor.java:199) > at org.jboss.cache.interceptors.LockInterceptor.invoke(LockInterceptor.java:144) > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40) > at org.jboss.cache.interceptors.CreateIfNotExistsInterceptor.invoke(CreateIfNotExistsInterceptor.java:145) > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40) > at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:35) > at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:2998) > at org.jboss.cache.TreeCache.put(TreeCache.java:1657) > at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$MyUpgrader._run(TxDeadlockUnitTestCase.java:346) > at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213) > at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213) > and > testConcurrentUpgrade(): > MyThread#1: get(/a/b/c) > MyThread#2: get(/a/b/c) > MyThread#2: done, locks: > /a (read owners=[<null>:2]) > /b (read owners=[<null>:2]) > /c (read owners=[<null>:2]) > MyThread#1: done, locks: > /a (read owners=[<null>:2, <null>:1]) > /b (read owners=[<null>:2, <null>:1]) > /c (read owners=[<null>:2, <null>:1]) > MyThread#2: put(/a/b/c) > MyThread#1: put(/a/b/c) > MyThread#1: org.jboss.cache.lock.LockingException: acquireWriteLock(): lock upgrade failed for /a/b/c (caller=<null>:1); - nested throwable: (org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock) > MyThread#2: org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:1] > Write lock owner: null > (caller=<null>:2) > org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:1] > Write lock owner: null > (caller=<null>:2) > at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:155) > at org.jboss.cache.Node.acquireWriteLock(Node.java:448) > at org.jboss.cache.Node.acquire(Node.java:417) > at org.jboss.cache.interceptors.LockInterceptor.lock(LockInterceptor.java:199) > at org.jboss.cache.interceptors.LockInterceptor.invoke(LockInterceptor.java:144) > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40) > at org.jboss.cache.interceptors.CreateIfNotExistsInterceptor.invoke(CreateIfNotExistsInterceptor.java:145) > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40) > at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:35) > at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:2998) > at org.jboss.cache.TreeCache.put(TreeCache.java:1657) > at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$MyThread._run(TxDeadlockUnitTestCase.java:317) > at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213) > at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213) -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-736) PojoCache passivation failure

by Ben Wang (JIRA)

PojoCache passivation failure ----------------------------- Key: JBCACHE-736 URL: http://jira.jboss.com/jira/browse/JBCACHE-736 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: PojoCache Affects Versions: 1.4.0 Reporter: Ben Wang Assigned To: Ben Wang In release 1.4 of PojoCache, passivation won't work becuase the new AopEvictionInterceptor and that we override the evict method such that we issue recursiveEvict that in turn is doing _remove(). Becuase of this, it bypasses the passivation interceptor. However, the fix is not so obvious. As it also involves the eviction paradigm for POJo as well. In 2.0 instead, I have opted for not to over-ride evict such that we would only support passivation on a node basis (instead of POJO). This way, passivation is transparent to the POJO level. I have a passivation package to test out these cases. -- 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, 3 months

3
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-947) Optimization in attach and detach; reduce calls to getPojo()

by Elias Ross (JIRA)

Optimization in attach and detach; reduce calls to getPojo() ------------------------------------------------------------ Key: JBCACHE-947 URL: http://jira.jboss.com/jira/browse/JBCACHE-947 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: PojoCache Affects Versions: PojoCache Reporter: Elias Ross Assigned To: Ben Wang PojoCache.attach() calls getPojo() at least three times. Once in putObjectI() to determine if the existing object is the same as the attaching object (fairly rare condition), then once again in putObjectII() (which might be redundant.) Then, it calls detach() which calls getPojo() -- see below. I believe that simply calling pCache.detach() and returning the old value might be sufficient. Also, detach() likewise locates the object before removal, though the removal method itself returns the original object. This is because notification includes the original object before removal. In some cases, notification may not be required. It may also be better to refactor the notification listener so that every removal doesn't require two calls to "getPojo". I discovered this following the number of calls made in a profiler tool. -- 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, 3 months

2
1
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 April 2007