July 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Commented: (JBCACHE-54) PojoCache needs a customized interceptor option

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-54?page=comments#action_12339740 ] Ben Wang commented on JBCACHE-54: --------------------------------- Since 2.0, we use AOP based interceptor stack, user can specify directly the interceptor stack among different methods in the jboss-aop.xml. All we need to do is making sure it is well documented. > PojoCache needs a customized interceptor option > ----------------------------------------------- > > Key: JBCACHE-54 > URL: http://jira.jboss.com/jira/browse/JBCACHE-54 > Project: JBoss Cache > Issue Type: Feature Request > Components: PojoCache > Affects Versions: 1.2.1 > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: 2.0.0 > > Original Estimate: 4 weeks > Remaining Estimate: 4 weeks > > In designing the implementation of http session repl using JBossCacheAop, there is a need to add a customized interceptor (in addition to the CacheInterceptor) to handle specific session request. > This feature can be generalized to a generic customized interceptor chain that a user of aop can add to his own. Idea then is the chain (of which starts with the CacheInterceptor) will be added as a dynamic aop interceptors. > This requires refactoring of current TreeCacheAop such that certain method calls can be expressed a pointcut such that we can bind customized interceptors there. -- 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

20 years

1
0
0 / 0

[JBoss JIRA] Commented: (JBCACHE-450) Create a pure pojo-based eviction policy

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-450?page=comments#action_12339739 ] Ben Wang commented on JBCACHE-450: ---------------------------------- After some further thinking, I conclude that eviction is really not well suited in PojoCache. Again, it will have to run as part of passivation. Here is why. If we use eviction only to evict the pojo then: 1. When evicted, the cache content will be empty (i.e., no long available). What happens to the interceptor? Do we remove it as well or not? If we keep the interceptor, what happens when the pojo is accessed again, e.g., pojo.getAge()? It will return null since the cache content has been evicted already. 2. However, if decide to remove the corresponding iterceptor, then pojo.getAge() will return correctly. However, pojo.setAge(21) won't be intercepted by the cache interceptor. It will be just a regular pojo operation. This is a semantic change that user won't be aware of. 3. For pojo-based eviction, if a sub-object is refereshed, we will need to refresh the corresponding parent object as well. E.g., if address is refershed, then Person needs to be refreshed (i.e., no evicted). We need to take care of multiple references as well. We can do this in 2.0 since we keep track of like of parent object from the sub-object. Nonetheless, it is not as straightforward. 4. What happens at the remote node if it is a passive node (e.g., only failing over purpose). Then the pojo won't be evicted since officially there won't be one yet (untill the user do cache.find(id)) So I think the best way is go with passivation. If we use passivation, we can use the current cache node-level eviction policy. We really don't care about the pojo level since from PojoCache point of view, the fqn value is always available, e.g., when I do a pojo.getAge(), behind the scene, the cache loader will retrieve the value associated with the age item, e.g., cache.get(id, "age"). This way, we are totally transparent. Couple things to take notice though: 1. When it is passivated, if the pojo becomes orphan (i.e., no one is referencing it anymore), GC will kick in. Originally, the pojo reference is also stored under AOPInstance (as a strong reference) but now AOPInstance has been passivated already (and the reference field is a transient modifier), so GC can freely to collect the pojo instance. No problem in the vm. 2. The only problem though is what happens to the data in the cache loader store? Since the pojo has been GCed, most likely no one will use it (unless, I am using cache.find(id) again to resurrect it), we will need to come up a way to trim it or age out. We can have a separate timer thread to weed out the ageout items. 3. This is the scenario: cache.attach("pojo", pojo); pojo.setName("Ben"); ... // it is passivated pojo.getName(); // no problem here Pojo anotherPojo = cache.find("pojo"); then pojo != anotherPojo because getAopInstance() return nulls during find (becuase it is a transient field). Can we come up a way to serialize the pojo reference but not replicating it? If somehow AopInstance contains non-transient pojo reference but AopInstance is stored as a local cache mode (e.g., doesnt replicate), then it is serializable but not replicatable. As a result, case solved. If we can't, then everything will work fine actually, e.g., pojo and anotherPojo can do indepdent update and get. But only comparison of object identity (by reference) will fail. > Create a pure pojo-based eviction policy > ---------------------------------------- > > Key: JBCACHE-450 > URL: http://jira.jboss.com/jira/browse/JBCACHE-450 > 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: 1 week > Remaining Estimate: 1 week > > The eviction policy module has been refactored in 1.3. We will need to refactor the pojo-based evitction policy 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

20 years

1
0
0 / 0

[JBoss JIRA] Assigned: (JBTM-81) Delay start of recovery manager

by Mark Little (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-81?page=all ] Mark Little reassigned JBTM-81: ------------------------------- Assignee: Kevin Conner (was: Mark Little) > Delay start of recovery manager > ------------------------------- > > Key: JBTM-81 > URL: http://jira.jboss.com/jira/browse/JBTM-81 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JTS Implementation, JTA Implementation > Affects Versions: 4.2 > Reporter: Mark Little > Assigned To: Kevin Conner > Priority: Minor > > Currently the Recovery Manager begins working as soon as JBossAS starts. When the local JTA implementation is used and there is a transaction to recover, we get the following stack trace: > 10:52:35,529 WARN [loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.restorestate] [com.arjuna.ats.interna\ > l.jta.resources.arjunacore.restorestate] Exception on attempting to restore XAResource > java.io.StreamCorruptedException: unexpected end of block data > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1321) > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1713) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.restore_state(XAResourceRecord.java:879) > at com.arjuna.ats.arjuna.coordinator.BasicAction.restore_state(BasicAction.java:1410) > at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:711) > at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:673) > at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.<init>(RecoverAtomicAction.java:60) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecovery\ > Module.java:178) > This is because the rest of the system isn't yet fully initialised. The next periodic run of recovery does not suffer this problem and recovery completes successfully. We should look at delaying the start of the Recovery Manager until JBossAS is fully initialised. -- 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

20 years

1
0
0 / 0

[JBoss JIRA] Resolved: (JBTM-51) Update the demonstrator for JavaOne

by Kevin Conner (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-51?page=all ] Kevin Conner resolved JBTM-51. ------------------------------ Resolution: Done > Update the demonstrator for JavaOne > ----------------------------------- > > Key: JBTM-51 > URL: http://jira.jboss.com/jira/browse/JBTM-51 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JTS Implementation, WS-T Implementation, Documentation, Demonstrator > Reporter: Mark Little > Assigned To: Kevin Conner > Fix For: 4.2.1 > > Time Spent: 1 day > Remaining Estimate: 0 minutes > > We are giving a BOF of Web Services transactions and J2EE at JavaOne 2006. We need to make sure the demonstrator is appropriate for the BOF. -- 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

20 years

1
0
0 / 0

[JBoss JIRA] Closed: (JBTM-51) Update the demonstrator for JavaOne

by Kevin Conner (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-51?page=all ] Kevin Conner closed JBTM-51. ---------------------------- > Update the demonstrator for JavaOne > ----------------------------------- > > Key: JBTM-51 > URL: http://jira.jboss.com/jira/browse/JBTM-51 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JTS Implementation, WS-T Implementation, Documentation, Demonstrator > Reporter: Mark Little > Assigned To: Kevin Conner > Fix For: 4.2.1 > > Time Spent: 1 day > Remaining Estimate: 0 minutes > > We are giving a BOF of Web Services transactions and J2EE at JavaOne 2006. We need to make sure the demonstrator is appropriate for the BOF. -- 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

20 years

1
0
0 / 0

[JBoss JIRA] Closed: (JBTM-63) Make sure 4.2.1 works stand-alone as well as embeded

by Mark Little (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-63?page=all ] Mark Little closed JBTM-63. --------------------------- Resolution: Done > Make sure 4.2.1 works stand-alone as well as embeded > ---------------------------------------------------- > > Key: JBTM-63 > URL: http://jira.jboss.com/jira/browse/JBTM-63 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 4.2 > Reporter: Mark Little > Assigned To: Mark Little > Fix For: 4.2.1 > > -- 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

20 years

1
0
0 / 0

[JBoss JIRA] Created: (JBTM-99) Fine grained control over setTransactionTimeout execution

by Kevin Conner (JIRA)

Fine grained control over setTransactionTimeout execution --------------------------------------------------------- Key: JBTM-99 URL: http://jira.jboss.com/jira/browse/JBTM-99 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JTA Implementation, JTS Implementation Affects Versions: 4.2 Reporter: Kevin Conner Assigned To: Kevin Conner We need to add fine grained control to the transaction timeout handling code. Areas covered by this include - transaction inflow - timeout propagation to resources -- 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

20 years

1
0
0 / 0

[JBoss JIRA] Closed: (JBTM-93) Oracle setTransactionTimeout only propagates to server during XAResource.start method invocation

by Kevin Conner (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-93?page=all ] Kevin Conner closed JBTM-93. ---------------------------- > Oracle setTransactionTimeout only propagates to server during XAResource.start method invocation > ------------------------------------------------------------------------------------------------ > > Key: JBTM-93 > URL: http://jira.jboss.com/jira/browse/JBTM-93 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JTA Implementation, JTS Implementation > Affects Versions: 4.2 > Reporter: Kevin Conner > Assigned To: Kevin Conner > Fix For: 4.2.1 > > Time Spent: 1 day > Remaining Estimate: 0 minutes > > Invocations of the XAResource.setTransactionTimeout method are cached by the Oracle driver until a call to the XAResource.start method has occurred. > The Type 4 driver accepts the new value and stores it locally but this does not appear to be propagated except as part of the start method invocation. -- 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

20 years

1
0
0 / 0

[JBoss JIRA] Resolved: (JBTM-93) Oracle setTransactionTimeout only propagates to server during XAResource.start method invocation

by Kevin Conner (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-93?page=all ] Kevin Conner resolved JBTM-93. ------------------------------ Resolution: Done > Oracle setTransactionTimeout only propagates to server during XAResource.start method invocation > ------------------------------------------------------------------------------------------------ > > Key: JBTM-93 > URL: http://jira.jboss.com/jira/browse/JBTM-93 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JTA Implementation, JTS Implementation > Affects Versions: 4.2 > Reporter: Kevin Conner > Assigned To: Kevin Conner > Fix For: 4.2.1 > > Time Spent: 1 day > Remaining Estimate: 0 minutes > > Invocations of the XAResource.setTransactionTimeout method are cached by the Oracle driver until a call to the XAResource.start method has occurred. > The Type 4 driver accepts the new value and stores it locally but this does not appear to be propagated except as part of the start method invocation. -- 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

20 years

1
0
0 / 0

[JBoss JIRA] Commented: (JBTM-93) Oracle setTransactionTimeout only propagates to server during XAResource.start method invocation

by Kevin Conner (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-93?page=comments#action_12339734 ] Kevin Conner commented on JBTM-93: ---------------------------------- The order of the method invocations has been swapped and the setTransactionTimeout is now configurable. There are two ways to configure this functionality - specify the com.arjuna.ats.jta.xaTransactionTimeoutEnabled property (defaults to true) - programmatically using the setXATransactionTimeoutEnabled method on com.arjuna.ats.jta.common.Configuration (Boolean.TRUE/enabled, Boolean.FALSE/disabled, null/use property value) > Oracle setTransactionTimeout only propagates to server during XAResource.start method invocation > ------------------------------------------------------------------------------------------------ > > Key: JBTM-93 > URL: http://jira.jboss.com/jira/browse/JBTM-93 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JTA Implementation, JTS Implementation > Affects Versions: 4.2 > Reporter: Kevin Conner > Assigned To: Kevin Conner > Fix For: 4.2.1 > > > Invocations of the XAResource.setTransactionTimeout method are cached by the Oracle driver until a call to the XAResource.start method has occurred. > The Type 4 driver accepts the new value and stores it locally but this does not appear to be propagated except as part of the start method invocation. -- 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

20 years

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 July 2006