7:39 p.m.
OK, so we are saying XXxDirect belongs in NodeSPI because they are used only for cache
behavior customization? But I'd like the explict naming in this case. Previously, you
always need to remember to set the option each time before the method call.
Another minor issue that I find in my unit test:
java.lang.UnsupportedOperationException: Cannot directly retrieve children which
aren't directly under the current node.
at org.jboss.cache.UnversionedNode.getChildDirect(UnversionedNode.java:424)
It seems now:
NodeSPI node = cache.getRoot().getChildDirect(fqn);
Only support the retrieval of immediate child. So if, say, I have "/a/b/c" fqn
that I want to retrieve from getRoot(), what is my option then? I'd think to iterate
through the Node tree to get a child node is quite tedious and inefficient.
Thanks,
-Ben
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org
[mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Manik Surtani
Sent: Thursday, January 04, 2007 10:47 PM
To: jbosscache-dev(a)lists.jboss.org
Subject: [jbosscache-dev] API changes in Habanero
Guys,
Here are a few major refactorings I've done on HEAD (checked in already). Some of
these are on the API level and do affect the way interceptors and other subsystems
interact with the node structure, hence the email.
* Got rid of the horrible BypassInterceptorChain malarky when interacting with nodes and
you don't want calls up the interceptor chain
* Used by interceptors themselves, as well as other internal subsystems including state
transfer and the cache itself.
* BypassInterceptorChain will still exist as an Option, as there are some valid use cases
for this.
* This option is now SOLELY handled by the InvocationContextInterceptor, which directs
the call to the last interceptor in the chain if the option is present
* Not handled internally in Node implementation methods anymore
* Replaced with a bunch of XXXDirect() methods on NodeSPI for direct
interaction/bypassing interceptor chains
* E.g., Node.getChild(Fqn f) goes up the interceptor chain, NodeSPI.getChildDirect(Fqn
f) operates directly on the node.
* Benefits: much easier to read, understand and maintain, more performant.
* Got rid of Node.getNodeSPI()
* NodeSPI interface can now be easily obtained since all methods on NodeSPI which would
otherwise return Node now return NodeSPI
* Methods on Cache (such as getRoot()) which would return Node are overridden in CacheSPI
to return NodeSPI.
* Gives interceptors and the like access to NodeSPI without letting this interface escape
to the user API.
* There are still a very small handful of cases where direct casts are necessary, but
this is very internalised (within UnversionedNode and WorkspaceNode, for example) and a
bunch of unit tests (for closer
inspection)
* In general, NodeSPI is now much tighter and can only officially be obtained from
another NodeSPI or a CacheSPI.
* Got rid of NodeSPI.getRawData() - superfluous now that we have
NodeSPI.getDataDirect()
This stuff should give us a much more robust data model and user/SPI interface for the
nodes and caches.
Please let me know what you think or if you have any issues/further suggestions.
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
2:30 a.m.
New subject: API changes in Habanero
On 5 Jan 2007, at 01:39, Ben Wang wrote:
OK, so we are saying XXxDirect belongs in NodeSPI because they are
used only for cache behavior customization? But I'd like the
explict naming in this case. Previously, you always need to
remember to set the option each time before the method call.
Not really for cache behaviour customisation at all, but for direct
node access.
E.g., Node.get(Object key) could do 2 things:
1) pass a call up the interceptor stack, to make sure the node is
locked, cache loaders are considered, etc etc, and then retrieve the
value of some data in the node.
2) or it could ignore the interceptor stack and retrieve some data
from the node's data map.
In JBC 1.x, (1) was never supported directly from a node. You had to
go through TreeCache to do this. Node.get() always performed (2).
in 2.0.0.ALPHA1, both (1) and (2) were supported, depending on
whether BypassInterceptorChain was set to true as an option. I
explained earlier how this is ugly, cumbersome, and not performant
(constant checking of a thread-local variable)
This is why for 2.0.0.ALPHA2, I split such methods into 2 separate
ones. Node.get(Object key) performs (1) above. NodeSPI.getDirect
(Object fqn) performs (2) above. This also nicely encapsulates
direct access from the user API.
I'm not sure what you meant by explicit naming, I thought this is
what I have achieved here. :-) Previously naming was ambiguous in
that the method performed one of two things - (1) or (2) above -
based on an option passed in. Really bad design to rely on a
'global' like that. :-)
Another minor issue that I find in my unit test:
java.lang.UnsupportedOperationException: Cannot directly retrieve
children which aren't directly under the current node.
at org.jboss.cache.UnversionedNode.getChildDirect
(UnversionedNode.java:424)
It seems now:
NodeSPI node = cache.getRoot().getChildDirect(fqn);
Only support the retrieval of immediate child. So if, say, I have "/
a/b/c" fqn that I want to retrieve from getRoot(), what is my
option then? I'd think to iterate through the Node tree to get a
child node is quite tedious and inefficient.
Yes, I put this in since I was trying to emulate direct child access
for the node in the xxxDirect() methods. But you are correct, I
don't see why this has to be the case and I have changed it in CVS
HEAD to not throw this exception and walk the tree internally.
I also need to update the javadocs on the xxxDirect() methods to
state that the onus is on the caller to make sure appropriate locks
are obtained, etc. as this call does not go through the interceptor
chain. Given that the intent of these methods are for SPI use only,
typically from within an interceptor, the user of the SPI would be
aware of such constraints and be able to deal with it.
And as a tangent, I was thinking about checking on access for such
direct methods and wanted everyone's ideas:
At the moment, xxxDirect() methods that access, for example, the
child map or data map of a node are synchronized. Now this is
overkill, but it enforces correctness. Since we assume that callers
to the xxxDirect() methods obtain appropriate locks in all cases, is
it safe to remove the synchronization, and instead add a lock-
ownership check to such methods.
For example:
public Object getDirect(Object key)
{
if (!getLock().getReaderOwners().contains(Thread.currentThread()))
throw new CacheException("Current thread does not have a read lock
on node " + fqn);
return data == null? null : data.get(key);
}
This would pretty rightly encapsulate and enforce concurrent access
rules on the nodes, even with direct access. And cheaper than
synchronizing the direct access methods. What do you guys think?
Cheers,
Manik
Thanks,
-Ben
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-
bounces(a)lists.jboss.org] On Behalf Of Manik Surtani
Sent: Thursday, January 04, 2007 10:47 PM
To: jbosscache-dev(a)lists.jboss.org
Subject: [jbosscache-dev] API changes in Habanero
Guys,
Here are a few major refactorings I've done on HEAD (checked in
already). Some of these are on the API level and do affect the way
interceptors and other subsystems interact with the node structure,
hence the email.
* Got rid of the horrible BypassInterceptorChain malarky when
interacting with nodes and you don't want calls up the interceptor
chain
* Used by interceptors themselves, as well as other internal
subsystems including state transfer and the cache itself.
* BypassInterceptorChain will still exist as an Option, as there
are some valid use cases for this.
* This option is now SOLELY handled by the
InvocationContextInterceptor, which directs the call to the last
interceptor in the chain if the option is present
* Not handled internally in Node implementation methods anymore
* Replaced with a bunch of XXXDirect() methods on NodeSPI for
direct interaction/bypassing interceptor chains
* E.g., Node.getChild(Fqn f) goes up the interceptor chain,
NodeSPI.getChildDirect(Fqn f) operates directly on the node.
* Benefits: much easier to read, understand and maintain, more
performant.
* Got rid of Node.getNodeSPI()
* NodeSPI interface can now be easily obtained since all methods
on NodeSPI which would otherwise return Node now return NodeSPI
* Methods on Cache (such as getRoot()) which would return Node are
overridden in CacheSPI to return NodeSPI.
* Gives interceptors and the like access to NodeSPI without
letting this interface escape to the user API.
* There are still a very small handful of cases where direct casts
are necessary, but this is very internalised (within
UnversionedNode and WorkspaceNode, for example) and a bunch of unit
tests (for closer
inspection)
* In general, NodeSPI is now much tighter and can only officially
be obtained from another NodeSPI or a CacheSPI.
* Got rid of NodeSPI.getRawData() - superfluous now that we have
NodeSPI.getDataDirect()
This stuff should give us a much more robust data model and user/
SPI interface for the nodes and caches.
Please let me know what you think or if you have any issues/further
suggestions.
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
6535
days inactive
6535
days old
jbosscache-dev@lists.jboss.org
1 comments
2 participants
participants (2)
-
Ben Wang -
Manik Surtani