August 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBCACHE-527) findObjects return pojos are not necessarily Serializable

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-527?page=all ] Ben Wang updated JBCACHE-527: ----------------------------- Fix Version/s: PojoCache 2.1.0 (was: PojoCache) > findObjects return pojos are not necessarily Serializable > --------------------------------------------------------- > > Key: JBCACHE-527 > URL: http://jira.jboss.com/jira/browse/JBCACHE-527 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Ben Wang > Priority: Minor > Fix For: PojoCache 2.1.0 > > > Currently, the MBean api, findObjects(fqn) return Map that contains fqn and pojos. However, this can't be used in remote call since pojos are not have to be Serializable. User can however, make it Serializable. Or need to come up another way to make it so. This is desirable for monitoring purposes so we know which pojos are current in store. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-497) NetworkManagementAopTest failure

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-497?page=all ] Ben Wang resolved JBCACHE-497. ------------------------------ Resolution: Out of Date > NetworkManagementAopTest failure > -------------------------------- > > Key: JBCACHE-497 > URL: http://jira.jboss.com/jira/browse/JBCACHE-497 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: PojoCache > > > We are seeing random failure on testSharedNodeAndElement. Here is the stack trace: > TreeCacheAop.endTransaction(): > java.lang.RuntimeException: TreeCacheAop.endTransaction(): at org.jboss.cache.aop.TreeCacheAop.endTransaction(TreeCacheAop.java:488) at org.jboss.cache.aop.TreeCacheAop.putObject(TreeCacheAop.java:371) at org.jboss.cache.aop.TreeCacheAop.putObject(TreeCacheAop.java:323) at org.jboss.cache.aop.integrated.NetworkManagementAopTest.testSharedNodeAndElement(NetworkManagementAopTest.java:187) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)Caused by: javax.transaction.RollbackException at org.jboss.cache.transaction.DummyTransaction.commit(DummyTransaction.java:67) at org.jboss.cache.transaction.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:60) at org.jboss.cache.aop.TreeCacheAop.endTransaction(TreeCacheAop.java:481) ... 18 more > This is not the first time I have seen this so we will need to investigate this. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-585) PojoCache Collection class when detached, the in-memory fields are not updated

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-585?page=all ] Ben Wang updated JBCACHE-585: ----------------------------- Fix Version/s: PojoCache 2.1.0 (was: PojoCache) > PojoCache Collection class when detached, the in-memory fields are not updated > ------------------------------------------------------------------------------ > > Key: JBCACHE-585 > URL: http://jira.jboss.com/jira/browse/JBCACHE-585 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Ben Wang > Priority: Minor > Fix For: PojoCache 2.1.0 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > This happens during the refactoring of Collections class (JBCACHE-580). For speed reason, I choose not to update it now. But we can make it configurable for performance optimization. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-619) PojoCache to support JDK5.0 Enum

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-619?page=all ] Ben Wang updated JBCACHE-619: ----------------------------- Fix Version/s: PojoCache 2.1.0 (was: PojoCache) > PojoCache to support JDK5.0 Enum > -------------------------------- > > Key: JBCACHE-619 > URL: http://jira.jboss.com/jira/browse/JBCACHE-619 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: PojoCache 2.1.0 > > Original Estimate: 4 days > Remaining Estimate: 4 days > > In JDK5.0, Enum is Serializabe. We need to look into whether it is possible to intercept Enum operation as well. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-686) PojoCache handling undo of Collection classes properly

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-686?page=all ] Ben Wang updated JBCACHE-686: ----------------------------- Fix Version/s: 2.0.0 (was: PojoCache) > PojoCache handling undo of Collection classes properly > ------------------------------------------------------ > > Key: JBCACHE-686 > URL: http://jira.jboss.com/jira/browse/JBCACHE-686 > Project: JBoss Cache > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: 2.0.0 > > > Currently in 2.0, the undo is completed for regular attach. But for attachment involving the Collection classes, nothing has been done yet. Mostly, we need to handle the CollectionInterceptor.attach and detach. We will wait until the interal refactoring is completed first. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-681) PojoCache to handle jdom documentation

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-681?page=all ] Ben Wang updated JBCACHE-681: ----------------------------- Fix Version/s: 2.0.0 (was: PojoCache) > PojoCache to handle jdom documentation > -------------------------------------- > > Key: JBCACHE-681 > URL: http://jira.jboss.com/jira/browse/JBCACHE-681 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: 2.0.0 > > > Idea is to replicate the jdom tree easily with PojoCache. The fine-grained replication can be more efficient. Also object relationship like cycles and inheritance can be handled automatically as well. > We will need to come up a more concrete example. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-674) PojoCache to handle simultaneous pojo attach on the clustering nodes

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-674?page=all ] Ben Wang updated JBCACHE-674: ----------------------------- Fix Version/s: PojoCache 2.2.0 (was: PojoCache) > PojoCache to handle simultaneous pojo attach on the clustering nodes > -------------------------------------------------------------------- > > Key: JBCACHE-674 > URL: http://jira.jboss.com/jira/browse/JBCACHE-674 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: PojoCache 2.2.0 > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Currently we don't handle cases with active attachment of pojo on all clustering nodes. For example, > cacheA.attach("1", pojo1); > cacheB.attach("1", pojo2); > pojo2 will overwrite pojo1 but pojo1 will still have cache interceptor attached to it. So solution will have to be some sort of check dirty mechanism when any POJO operation is called. But this will introduce more overheads. > Still need to gather more use case for this. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-658) Fast locking for mostly-read PojoCache

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-658?page=all ] Ben Wang updated JBCACHE-658: ----------------------------- Fix Version/s: 2.0.0 (was: PojoCache) > Fast locking for mostly-read PojoCache > -------------------------------------- > > Key: JBCACHE-658 > URL: http://jira.jboss.com/jira/browse/JBCACHE-658 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Nitzan Niv > Assigned To: Ben Wang > Fix For: 2.0.0 > > > The locking mechanism locks all the nodes in the path from the tree root to the modified node. If the cache contains a deep hierarchy of nodes (e.g., PojoCache that contains complex objects) and the usage of the cache > is mostly-read the locking overhead is unnecessarilly large. > To enable REPEATABLE_READ isolation level with minimal overhead (but with reduced update parallelism) just the tree root should be locked instead of the nodes-path. To define this policy as a new isloation level ("single"): > Change in PessimisticLockInterceptor (line 199): > else { > if(isolation_level == IsolationLevel.SINGLE) {//XXX > if (i == 0) { > acquired=child_node.acquire(owner, lock_timeout, lock_type); > } > } else { > if(lock_type == DataNode.LOCK_TYPE_WRITE && i == (treeNodeSize - 1)) { > acquired=child_node.acquire(owner, lock_timeout, DataNode.LOCK_TYPE_WRITE); > } > else { > acquired=child_node.acquire(owner, lock_timeout, DataNode.LOCK_TYPE_READ); > } > }//XXX > } > in LockStrategyFactory.java: > if (lockingLevel == IsolationLevel.REPEATABLE_READ || lockingLevel == IsolationLevel.SINGLE) //XXX > return new LockStrategyRepeatableRead(); > and add the "SINGLE" isolation level to IsolationLevel.java. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-453) support @Interceptor annotation

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-453?page=all ] Ben Wang resolved JBCACHE-453. ------------------------------ Resolution: Won't Fix With 2.0 release, use can specify interceptor directly via aop. So this is no longer needed. > support @Interceptor annotation > ------------------------------- > > Key: JBCACHE-453 > URL: http://jira.jboss.com/jira/browse/JBCACHE-453 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: PojoCache > > Original Estimate: 2 days > Remaining Estimate: 2 days > > If supported when @Interceptor is applied to the intercepted field, it will call the interceptor class first for customization. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-675) Test case failure RecursiveRefTest

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-675?page=all ] Ben Wang updated JBCACHE-675: ----------------------------- Fix Version/s: 2.0.0 (was: PojoCache) > Test case failure RecursiveRefTest > ---------------------------------- > > Key: JBCACHE-675 > URL: http://jira.jboss.com/jira/browse/JBCACHE-675 > Project: JBoss Cache > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Scott Marlow > Fix For: 2.0.0 > > > The fix to require key as Serialiable cuases this test case: > org.jboss.cache.pojo.RecrusiveRefTest to fail because in there it is put(valueId, valueObject) where valueId is a PojoCacheable object (but not Serializable). It is PojoCacheable becuase valueObject also uses valueId as the primary key. -- 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, 11 months

1
0
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 August 2006