RE: [jbosscache-dev] Problems with node locking semantics in JBC1.4.1.GA
by Brian Stansberry
Final installment in a conversation with myself ;)
The REPEATABLE_DATA_READ thing has a funny smell, but the ease with
which it was implemented makes me realize it's fairly easy to separate
decisions about the data map from decisions about the child map. Perhaps
a cache config flag, separate from IsolationLevel, could control the
same behavior. For want of a better name,
<attribute name="TreatChildInsertRemoveAsAWrite">true</attribute>
Even further, that could be treated as a cache wide default, used to set
a flag on each node. The PessimisticLockInterceptor could check that
flag to decide whether to get the WL. What's nice about that is the
cache wide default could be true, but for certain nodes the application
could set it to false. E.g the root node for a webapp under which
sessions are stored, root node for an SFSB or entity under which
instances are stored, PojoCache's _JBossInternal_ node etc. Simpler
alternative to lock striping on the child map.
Haven't thought about optimistic locking, as I'm not too familiar with
the details of handling child inserts/removes.
Brian Stansberry wrote:
> I played around with one way to deal with this.
>
> Speaking in db isolation terms, let's say a
> non-repeatable-read means a tx reads a node's *data map*
> twice and gets different results. A phantom read means a tx
> reads a node's *child map* twice and gets different results.
> Conceptually, a JBC node represents both a "row" (data map)
> and a query result set (children map -- set of rows that
> share a common characteristic that the parent represents). (I
> know this analogy is inexact, but, ...).
>
> In 1.4.0.SP1, REPEATABLE_READ meant you wouldn't get
> non-repeatable-reads, but could get phantom reads. With
> 1.4.1, you also don't get phantom reads (at least with
> respect to a node's immediate children). But, in many cases
> this behavior is unneeded and undesirable, and JBC no longer
> offers the old behavior.
>
> I attempted to remedy this with a new IsolationLevel
> REPEATABLE_DATA_READ, which basically provides the 1.4.0
> semantics. This was actually very easy to do.
>
> 1) LockStrategyFactory creates the same LockStrategy for
> REPEATABLE_DATA_READ as for REPEATABLE_READ -- hence lock
> behavior at the node level is unaffected.
>
> 2) PessimisticLockInterceptor uses the new level when
> deciding whether to WL a parent before adding/removing a
> node. Manik nicely encapsulated that logic, so it was
> simple to change. Here's a diff to the head of
> Branch_JBossCache_1_4_0:
>
> ### Eclipse Workspace Patch 1.0
> #P JBossCache
> Index:
> src/org/jboss/cache/interceptors/PessimisticLockInterceptor.java
> ===================================================================
> RCS file:
> /cvsroot/jboss/JBossCache/src/org/jboss/cache/interceptors/Pes
> simisticLockInterceptor.java,v
> retrieving revision 1.20.2.8
> diff -u -r1.20.2.8 PessimisticLockInterceptor.java
> ---
> src/org/jboss/cache/interceptors/PessimisticLockIntercept
> or.java 14 Dec 2006 12:51:48 -0000 1.20.2.8
> +++
> src/org/jboss/cache/interceptors/PessimisticLockIntercept
> or.java 28 Jan 2007 21:08:55 -0000
> @@ -41,6 +41,8 @@
> public class PessimisticLockInterceptor extends Interceptor {
> TransactionTable tx_table = null;
> +
> + boolean writeLockOnChildInsertRemove = true;
>
> /**
> * Map<Object, java.util.List>. Keys = threads, values =
> lists of locks held by that thread @@ -55,6 +57,7 @@
> tx_table = cache.getTransactionTable();
> lock_table = cache.getLockTable();
> lock_acquisition_timeout = cache.getLockAcquisitionTimeout();
> + writeLockOnChildInsertRemove =
> (cache.getIsolationLevelClass() !=
> + IsolationLevel.REPEATABLE_DATA_READ);
> }
>
>
> @@ -323,12 +326,14 @@
>
> private boolean writeLockNeeded(int lock_type, int
> currentNodeIndex, int treeNodeSize, boolean
> isRemoveOperation, boolean createIfNotExists, Fqn targetFqn,
> Fqn currentFqn)
> {
> - if (isRemoveOperation && currentNodeIndex == treeNodeSize - 2)
> - return true; // we're doing a remove and we've
> reached the PARENT node of the target to be removed. -
> - if (!isTargetNode(currentNodeIndex, treeNodeSize) &&
> !cache.exists(new Fqn(currentFqn,
> targetFqn.get(currentNodeIndex + 1))))
> - return createIfNotExists; // we're at a node in the
> tree, not yet at the target node, and we need to create the
> next node. So we need a WL here.
> -
> + if (writeLockOnChildInsertRemove)
> + {
> + if (isRemoveOperation && currentNodeIndex ==
> treeNodeSize - 2)
> + return true; // we're doing a remove and we've
> reached the PARENT node of the target to be removed. +
> + if (!isTargetNode(currentNodeIndex, treeNodeSize)
> && !cache.exists(new Fqn(currentFqn,
> targetFqn.get(currentNodeIndex + 1))))
> + return createIfNotExists; // we're at a node in
> the tree, not yet at the target node, and we need to create
> the next node. So we need a WL here.
> + }
> return lock_type == DataNode.LOCK_TYPE_WRITE &&
> isTargetNode(currentNodeIndex, treeNodeSize) &&
> (createIfNotExists || isRemoveOperation); //normal operation,
> write lock explicitly requested and this is the target to be
> written to.
> }
>
>
> jbosscache-dev-bounces(a)lists.jboss.org wrote:
>> In 1.4.1.GA, we introduced node locking semantics that weren't there
>> in the previous few releases (and maybe never were there). This is
>> causing significant integration issues.
>>
>> Specifically, before inserting or removing a child node, we acquire a
>> WL on the parent. Previously, only a RL was acquired.
>>
>> I'm concerned about anomalies this might cause in apps that
>> intentionally or unintentionally depends on the old behavior.
>> For example, the AS http session repl code assumes it has freedom to
>> add/remove cache nodes that represent a session underneath the parent
>> that represents the webapp. Now these activities will block until any
>> activity on any other session is complete. With FIELD granularity,
>> that's a big issue, as locks are held throughout the web request. It
>> will likely cause issues with other granularities as well. (We
>> already saw a minor issue in a support case when a customer tried to
>> upgrade
>> 4.0.5 to 1.4.1).
>>
>> This definitely breaks the Hibernate (and thus EJB3 entity bean
>> clustering) integration with 1.4.1.GA. Basically, assume there is an
>> entity Person, with a child collection "children". Hibernate caches
>> the entity, and later caches the child collection in a child node.
>>
>> 1) Transaction tx = tm.begin();
>> 2) cache.get("/Person/Person#1/children", ITEM); // returns null --
>> not cached yet
>>
>> 3) read db to get the ids of the collection elements
>>
>> 4) tx.suspend();
>> 5) cache.putFailFast("/Person/Person#1/children", ITEM, data); 6)
>> tx.resume();
>>
>> This fails in step 5, because with the tx suspended, the
>> putFailFast() call cannot acquire the WL on /Person/Person#1 that it
>> needs to insert /Person/Person#1/children.
>>
>> Hmm, an EJB3 unit test shows that problem occuring, but I assume even
>> simple entity caching will break:
>>
>> 1) Transaction tx = tm.begin();
>> 2) cache.get("/Person/Person#2", ITEM); // returns null -- not
>> cached yet
>>
>> 3) read db to get the Person
>>
>> 4) tx.suspend();
>> 5) cache.putFailFast("/Person/Person#1", ITEM, data); 6) tx.resume();
>>
>> We need a quick workaround for this in the 1.4 branch, as it's a
>> blocker for EJB3 RC10 and AS 4.2.
>>
>> Brian Stansberry
>> Lead, AS Clustering
>> JBoss, a division of Red Hat
>> Ph: 510-396-3864
>> skype: bstansberry
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
19 years, 1 month
RE: [jbosscache-dev] Problems with node locking semantics in JBC1.4.1.GA
by Brian Stansberry
I played around with one way to deal with this.
Speaking in db isolation terms, let's say a non-repeatable-read means a
tx reads a node's *data map* twice and gets different results. A phantom
read means a tx reads a node's *child map* twice and gets different
results. Conceptually, a JBC node represents both a "row" (data map) and
a query result set (children map -- set of rows that share a common
characteristic that the parent represents). (I know this analogy is
inexact, but, ...).
In 1.4.0.SP1, REPEATABLE_READ meant you wouldn't get
non-repeatable-reads, but could get phantom reads. With 1.4.1, you also
don't get phantom reads (at least with respect to a node's immediate
children). But, in many cases this behavior is unneeded and undesirable,
and JBC no longer offers the old behavior.
I attempted to remedy this with a new IsolationLevel
REPEATABLE_DATA_READ, which basically provides the 1.4.0 semantics.
This was actually very easy to do.
1) LockStrategyFactory creates the same LockStrategy for
REPEATABLE_DATA_READ as for REPEATABLE_READ -- hence lock behavior at
the node level is unaffected.
2) PessimisticLockInterceptor uses the new level when deciding whether
to WL a parent before adding/removing a node. Manik nicely encapsulated
that logic, so it was simple to change. Here's a diff to the head of
Branch_JBossCache_1_4_0:
### Eclipse Workspace Patch 1.0
#P JBossCache
Index: src/org/jboss/cache/interceptors/PessimisticLockInterceptor.java
===================================================================
RCS file:
/cvsroot/jboss/JBossCache/src/org/jboss/cache/interceptors/PessimisticLo
ckInterceptor.java,v
retrieving revision 1.20.2.8
diff -u -r1.20.2.8 PessimisticLockInterceptor.java
--- src/org/jboss/cache/interceptors/PessimisticLockInterceptor.java
14 Dec 2006 12:51:48 -0000 1.20.2.8
+++ src/org/jboss/cache/interceptors/PessimisticLockInterceptor.java
28 Jan 2007 21:08:55 -0000
@@ -41,6 +41,8 @@
public class PessimisticLockInterceptor extends Interceptor
{
TransactionTable tx_table = null;
+
+ boolean writeLockOnChildInsertRemove = true;
/**
* Map<Object, java.util.List>. Keys = threads, values = lists of
locks held by that thread
@@ -55,6 +57,7 @@
tx_table = cache.getTransactionTable();
lock_table = cache.getLockTable();
lock_acquisition_timeout = cache.getLockAcquisitionTimeout();
+ writeLockOnChildInsertRemove = (cache.getIsolationLevelClass() !=
IsolationLevel.REPEATABLE_DATA_READ);
}
@@ -323,12 +326,14 @@
private boolean writeLockNeeded(int lock_type, int currentNodeIndex,
int treeNodeSize, boolean isRemoveOperation, boolean createIfNotExists,
Fqn targetFqn, Fqn currentFqn)
{
- if (isRemoveOperation && currentNodeIndex == treeNodeSize - 2)
- return true; // we're doing a remove and we've reached the
PARENT node of the target to be removed.
-
- if (!isTargetNode(currentNodeIndex, treeNodeSize) &&
!cache.exists(new Fqn(currentFqn, targetFqn.get(currentNodeIndex + 1))))
- return createIfNotExists; // we're at a node in the tree, not
yet at the target node, and we need to create the next node. So we need
a WL here.
-
+ if (writeLockOnChildInsertRemove)
+ {
+ if (isRemoveOperation && currentNodeIndex == treeNodeSize - 2)
+ return true; // we're doing a remove and we've reached the
PARENT node of the target to be removed.
+
+ if (!isTargetNode(currentNodeIndex, treeNodeSize) &&
!cache.exists(new Fqn(currentFqn, targetFqn.get(currentNodeIndex + 1))))
+ return createIfNotExists; // we're at a node in the tree,
not yet at the target node, and we need to create the next node. So we
need a WL here.
+ }
return lock_type == DataNode.LOCK_TYPE_WRITE &&
isTargetNode(currentNodeIndex, treeNodeSize) && (createIfNotExists ||
isRemoveOperation); //normal operation, write lock explicitly requested
and this is the target to be written to.
}
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> In 1.4.1.GA, we introduced node locking semantics that
> weren't there in the previous few releases (and maybe never
> were there). This is causing significant integration issues.
>
> Specifically, before inserting or removing a child node, we
> acquire a WL on the parent. Previously, only a RL was acquired.
>
> I'm concerned about anomalies this might cause in apps that
> intentionally or unintentionally depends on the old behavior.
> For example, the AS http session repl code assumes it has
> freedom to add/remove cache nodes that represent a session
> underneath the parent that represents the webapp. Now these
> activities will block until any activity on any other session
> is complete. With FIELD granularity, that's a big issue, as
> locks are held throughout the web request. It will likely
> cause issues with other granularities as well. (We already
> saw a minor issue in a support case when a customer tried to upgrade
> 4.0.5 to 1.4.1).
>
> This definitely breaks the Hibernate (and thus EJB3 entity bean
> clustering) integration with 1.4.1.GA. Basically, assume
> there is an entity Person, with a child collection
> "children". Hibernate caches the entity, and later caches
> the child collection in a child node.
>
> 1) Transaction tx = tm.begin();
> 2) cache.get("/Person/Person#1/children", ITEM); // returns
> null -- not cached yet
>
> 3) read db to get the ids of the collection elements
>
> 4) tx.suspend();
> 5) cache.putFailFast("/Person/Person#1/children", ITEM, data); 6)
> tx.resume();
>
> This fails in step 5, because with the tx suspended, the
> putFailFast() call cannot acquire the WL on /Person/Person#1
> that it needs to insert /Person/Person#1/children.
>
> Hmm, an EJB3 unit test shows that problem occuring, but I
> assume even simple entity caching will break:
>
> 1) Transaction tx = tm.begin();
> 2) cache.get("/Person/Person#2", ITEM); // returns null --
> not cached yet
>
> 3) read db to get the Person
>
> 4) tx.suspend();
> 5) cache.putFailFast("/Person/Person#1", ITEM, data); 6) tx.resume();
>
> We need a quick workaround for this in the 1.4 branch, as
> it's a blocker for EJB3 RC10 and AS 4.2.
>
> Brian Stansberry
> Lead, AS Clustering
> JBoss, a division of Red Hat
> Ph: 510-396-3864
> skype: bstansberry
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
19 years, 1 month
Problems with node locking semantics in JBC 1.4.1.GA
by Brian Stansberry
In 1.4.1.GA, we introduced node locking semantics that weren't there in
the previous few releases (and maybe never were there). This is causing
significant integration issues.
Specifically, before inserting or removing a child node, we acquire a WL
on the parent. Previously, only a RL was acquired.
I'm concerned about anomalies this might cause in apps that
intentionally or unintentionally depends on the old behavior. For
example, the AS http session repl code assumes it has freedom to
add/remove cache nodes that represent a session underneath the parent
that represents the webapp. Now these activities will block until any
activity on any other session is complete. With FIELD granularity,
that's a big issue, as locks are held throughout the web request. It
will likely cause issues with other granularities as well. (We already
saw a minor issue in a support case when a customer tried to upgrade
4.0.5 to 1.4.1).
This definitely breaks the Hibernate (and thus EJB3 entity bean
clustering) integration with 1.4.1.GA. Basically, assume there is an
entity Person, with a child collection "children". Hibernate caches the
entity, and later caches the child collection in a child node.
1) Transaction tx = tm.begin();
2) cache.get("/Person/Person#1/children", ITEM); // returns null -- not
cached yet
3) read db to get the ids of the collection elements
4) tx.suspend();
5) cache.putFailFast("/Person/Person#1/children", ITEM, data);
6) tx.resume();
This fails in step 5, because with the tx suspended, the putFailFast()
call cannot acquire the WL on /Person/Person#1 that it needs to insert
/Person/Person#1/children.
Hmm, an EJB3 unit test shows that problem occuring, but I assume even
simple entity caching will break:
1) Transaction tx = tm.begin();
2) cache.get("/Person/Person#2", ITEM); // returns null -- not cached
yet
3) read db to get the Person
4) tx.suspend();
5) cache.putFailFast("/Person/Person#1", ITEM, data);
6) tx.resume();
We need a quick workaround for this in the 1.4 branch, as it's a blocker
for EJB3 RC10 and AS 4.2.
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
19 years, 1 month
NCACHE
by Manik Surtani
Bela,
Remember that .NET port of JBC we once spoke about?
http://www.theserverside.com/news/thread.tss?thread_id=43950
Not that this is the same, but there obviously must be a market.
Interestingly, I wonder how they achieve serializing user data from
one platform to the next.
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
19 years, 1 month
migrating data stored in 1.x format to VAM format
by Galder Zamarreno
Hi all,
I'm deferring http://jira.jboss.com/jira/browse/JBCACHE-879 to BETA2 because I still need to write this: http://jira.jboss.com/jira/browse/JBCACHE-882
The reason I'm deferring it is because I can't see a straightforward way of doing such thing right now. Ideally, you should be able run a 1.x version (cache1) and a 2.x version (cache2) of JBC in the same VM so that you can do a loop of cache1.get() and call cache2.put(). However, I have doubts that that this approach will be free of class loading issues. What do you think?
I was wondering whether Region based could help here, but I can't see right now how this could be done.
Something I had in mind is having the capability of to start a cache with either 1.x marshalling or VAM marshalling, but oriented at being used only at the cache loader level. It wouldn't make much sense for replication because there's no hard data there.
I thought that you could start two instances of cache 2.x, first with 1.x. marshalling and the other one with VAM both pointing to different JDBCCacheLoader stores. You could then get from the first using normal mmarshalling and put in the second one which has VAM marshalling active, what do you think?
If you like the approach, I should be have it ready by BETA2.
This last approach looks simpler to me, what do you think?
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
19 years, 1 month
RE: [jbosscache-dev] Re: JBoss Cache User Guide
by Galder Zamarreno
Created a tinyurl for it :)
http://tinyurl.com/36q634
I'll have a read over the weekend, got 8 hours of train ride to Germany coming up :D
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Manik Surtani
Sent: 24 January 2007 19:13
To: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] Re: JBoss Cache User Guide
Ok, never mind the comments about incomplete doc'n for BETA1.
The user guide is now complete, although I would really appreciate
feedback on it and some time to tweak and improve on it for BETA2.
I've published the latest on
http://labs.jboss.com/file-access/default/members/jbosscache/
freezone/docs/2.0.0.Snapshot/index.html
Now to look at what's causing the few CC failures and get BETA1 tagged.
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
On 23 Jan 2007, at 19:30, Manik Surtani wrote:
> And we're only about just over halfway done. Sigh.
>
> What do people think, BETA1 with incomplete doc'n, or hold BETA1
> until I finish the user guide?
>
> Also, here is what I have so far, feedback will be *very* useful.
> FYI, up to and including chapter 6 is complete. Chapters 7 - 10
> have headings as place holders, and I need to write up and/or copy
> and paste content from the old docs. Section III (References) is
> basically copied from the old docs, and needs to be revisited to
> make sure these are still correct/relevant.
>
> http://labs.jboss.com/file-access/default/members/jbosscache/
> freezone/docs/2.0.0.Snapshot/index.html
>
> Cheers,
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
> Email: manik(a)jboss.org
> Telephone: +44 7786 702 706
> MSN: manik(a)surtani.org
> Yahoo/AIM/Skype: maniksurtani
>
>
>
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
19 years, 1 month
JBoss Cache User Guide
by Manik Surtani
And we're only about just over halfway done. Sigh.
What do people think, BETA1 with incomplete doc'n, or hold BETA1
until I finish the user guide?
Also, here is what I have so far, feedback will be *very* useful.
FYI, up to and including chapter 6 is complete. Chapters 7 - 10 have
headings as place holders, and I need to write up and/or copy and
paste content from the old docs. Section III (References) is
basically copied from the old docs, and needs to be revisited to make
sure these are still correct/relevant.
http://labs.jboss.com/file-access/default/members/jbosscache/
freezone/docs/2.0.0.Snapshot/index.html
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
19 years, 1 month
RE: [jbosscache-dev] Really DUMB API method
by Vladimir Blagojevic
Is defining interceptors within xml configuration file out of the
question?
If so, option 1) seems better to me. Maybe with clever object
abstractions adding even few interceptors would be not so hard.
Say you have InterceptorInjectionPoint that contains position (defined
in various way) and Interceptor itself or something like that....
Cheers.
> -----Original Message-----
> From: jbosscache-dev-bounces(a)lists.jboss.org
> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of
> Manik Surtani
> Sent: Tuesday, January 23, 2007 1:31 PM
> To: jbosscache-dev(a)lists.jboss.org
> Subject: [jbosscache-dev] Really DUMB API method
>
> Writing user guides does have it's merits.
>
> I picked up a really pointless method in CacheSPI.
>
> CacheSPI.add/removeInterceptor(), meant for people who want
> to inject their own custom interceptors in the chain.
>
> Great, very useful, but how does one get a hold of a CacheSPI
> to do this? CacheSPIs will get injected into the custom interceptor,
> *after* it is added to the chain, but until then, a user does
> not have a CacheSPI reference.
>
> I see 2 ways around this, each one as unpalatable as the next.
>
> 1. Overload createCache() methods in CacheFactory to pass in
> interceptor(s) to be added, and their relative positions in
> the chain. Ok if we're just adding one interceptor, horrible
> if we're adding several. We could have used varargs and it
> would have been fine if it was just interceptors we're
> passing in and not interceptors AND positions.
> 2. Pull up add/removeInterceptor() to Cache. Ugly for
> obvious reasons.
>
> Can anyone think of anything else?
>
> I'm holding back tagging BETA1 till the end of the week; now
> that CC is alive again I want to stabilise the code as well
> as some more work on the docs.
>
> Cheers,
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
> Email: manik(a)jboss.org
> Telephone: +44 7786 702 706
> MSN: manik(a)surtani.org
> Yahoo/AIM/Skype: maniksurtani
>
>
>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
19 years, 1 month
Really DUMB API method
by Manik Surtani
Writing user guides does have it's merits.
I picked up a really pointless method in CacheSPI.
CacheSPI.add/removeInterceptor(), meant for people who want to inject
their own custom interceptors in the chain.
Great, very useful, but how does one get a hold of a CacheSPI to do
this? CacheSPIs will get injected into the custom interceptor,
*after* it is added to the chain, but until then, a user does not
have a CacheSPI reference.
I see 2 ways around this, each one as unpalatable as the next.
1. Overload createCache() methods in CacheFactory to pass in
interceptor(s) to be added, and their relative positions in the
chain. Ok if we're just adding one interceptor, horrible if we're
adding several. We could have used varargs and it would have been
fine if it was just interceptors we're passing in and not
interceptors AND positions.
2. Pull up add/removeInterceptor() to Cache. Ugly for obvious reasons.
Can anyone think of anything else?
I'm holding back tagging BETA1 till the end of the week; now that CC
is alive again I want to stabilise the code as well as some more work
on the docs.
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
19 years, 1 month
JBossCache 2.0.0.BETA1
by Manik Surtani
How are we doing with this, guys?
My target is still to have frozen dev work on HEAD by the end of
today to tag BETA1, and then work on the few outstanding test
failures tomorrow and Wed and hand over to QA by Thu morning. Tasks
that are incomplete are going to get pushed to BETA2.
Unfortunately CC is still being a pain and we haven't seen it run in
a while; hopefully it will run well tonight after QA have increased
the timeouts and we should see results tomorrow morning.
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
19 years, 1 month