-
15. Re: Designing Habanero - Cache and Node interfaces and JSR-1
I will publish my PojoCache 2.0 API soon. However, some of it will depend on how Cache, epsecially the factory looks like first. So let's discuss it on our design meeting tomorrow then.
-
16. Re: Designing Habanero - Cache and Node interfaces and JSR-1
"ben.wang@jboss.com" wrote:
createIfNoteExist. It looks like we need to do addChild first to create a new node, is it correct?
Yes. Does away with the "implicit" creation of nodes, which IMO is a good thing. -
17. Re: Designing Habanero - Cache and Node interfaces and JSR-1
"ben.wang@jboss.com" wrote:
How do we instantiate the cache in a MBeanSerice under JBoss? Can you give an example?
Perhaps a CacheMBean - which is an adapter class that allows for setting the configuration and managing lifecycle as an MBean? Need to think about this one a bit more. I'll add this to our Vegas design session agenda. -
18. Re: Designing Habanero - Cache and Node interfaces and JSR-1
"ben.wang@jboss.com" wrote:
Will node.getData() go through any interceptor? Triggering any event? Is it modifiable?
The data will not be modifiable. All mods should go through the Node interface itself - Node.put(), Node.remove(), etc.
And yes, getData() will go through the interceptor stack and trigger a node visited event. -
19. Re: Designing Habanero - Cache and Node interfaces and JSR-1
"ben.wang@jboss.com" wrote:
What about node.move()? Will it have any event notification?
Yes. I presume this will trigger a nodeRemoved event and a nodeCreated event. I don't think it warrants a separate event - what do people think? -
20. Re: Designing Habanero - Cache and Node interfaces and JSR-1
"ben.wang@jboss.com" wrote:
Do you have a use case for getTransactionTable? Just curious.
Yes - the SPI is passed in to the interceptors and interceptors may need access to the TX table. (The TxInterceptor certainly does) -
21. Re: Designing Habanero - Cache and Node interfaces and JSR-1
"ben.wang@jboss.com" wrote:
Is getInterceptorChain returning a List that is modifiable such that we can customize it?
What about setInterceptorChain api?
Should interceptor chain modification be programmatic? Or should this only be allowed via the configuration XML? -
22. Re: Designing Habanero - Cache and Node interfaces and JSR-1
"ben.wang@jboss.com" wrote:
Can we have a getCurrentTransaction() api?
This is in the InvocationContext. You would doInvocationContext.getCurrentContext().getTransaction(); InvocationContext.getCurrentContext().getGlobalTransaction();
These are set by the TxInterceptor so they are made available to other interceptors down the chain, without (expensive) access to the txTable. Note that the invocation context only lives for the duration of an invocation though so client code will not be allowed to set these values and may not even see them. -
23. Re: Designing Habanero - Cache and Node interfaces and JSR-1
"genman" wrote:
CacheListener ... lots of methods for an interface.
I suggest creating an Event, and/or CacheEvent + NodeEvent, so you have
-1 as well, I agree with Bela. And I don't think 9 methods in a listener interface is too many.
And again like Bela suggested, we probably ought to provide an abstract implementation with no-ops of all of these for ease of implementation though. +1 to that. -
24. Re: Designing Habanero - Cache and Node interfaces and JSR-1
"genman" wrote:
CacheFactory ... the stop and start methods seem like they should belong on the Cache itself, sort of OOP standard practice. createCache() -- why the two methods, one with the "start" boolean? Why only String for the configuration?
Yeah, the more I think about it the more I agree with you that the lifecycle should be on the Cache interface. The "start" boolean is irrelevant if lifecycle is controlled by the cache.
The factory method could be overloaded - String, Url, File, etc - to point to the config file to be used."genman" wrote:
I would probably make CacheFactory an abstract base class and a static method with the signature "CacheFactory getFactory()". This will allow you to add more methods later on to do with configuration details.
-1 on this - I think it should be up to the developer in the end to subclass or wrap the factory to provide a singleton if they wish. Either way, the end user will have to use the implementation rather than the interface or abstract class when creating the factory. E.g.:CacheFactory cf = CacheFactoryImpl.getFactory();
orCacheFactory cf = new CacheFactoryImpl();
The latter will almost force the developer to wrap the factory construction in a singleton wrapper, thereby not exposing the impl class too much.
+1 on wrapping the config as a Configuration object - in fact this would also be passed on into the interceptors to configure the interceptors so a lot of the existing configuration is not held in TreeCache. -
25. Re: Designing Habanero - Cache and Node interfaces and JSR-1
"genman" wrote:
As a suggestion, you might want to go with java.util.concurrent.ConcurrentMap for your Map interfaces as well, to pick up some of those extra transaction methods.
I'm not entirely happy with Node extending Map or (ConcurrentMap) since the Node doesn't represent a single map but two maps (data and children). Hence the APIs on Node to return the data map and children map.
The reason why I return read-only maps rather than allow direct access to the map is so I can intercept calls on these maps, and pass them up the interceptor chains. -
26. Re: Designing Habanero - Cache and Node interfaces and JSR-1
Actually, as I was writing the above, I just thought of this (and perhaps this is what you meant in the first place, so apologies if I didn't get it the first time)
How about actually allowing direct access to the data and child maps? We could return a delegate or subclass to a (Concurrent)HashMap, which would make sure invocations are passed through the interceptor chain. Cleaner model, perhaps? -
27. Re: Designing Habanero - Cache and Node interfaces and JSR-1
"manik.surtani@jboss.com" wrote:
"genman" wrote:
CacheListener ... lots of methods for an interface.
I suggest creating an Event, and/or CacheEvent + NodeEvent, so you have
-1 as well, I agree with Bela. And I don't think 9 methods in a listener interface is too many.
Typically event listeners are single method interfaces. See javax.management.NotificationListener , also java.util.EventListener and others. It isn't just that there are too many methods, it's just that you'll run into API problems if you want to EXTEND the event information (e.g. pass in additional parameters) or add more possible events. -
28. Re: Designing Habanero - Cache and Node interfaces and JSR-1
"manik.surtani@jboss.com" wrote:
How about actually allowing direct access to the data and child maps? We could return a delegate or subclass to a (Concurrent)HashMap, which would make sure invocations are passed through the interceptor chain. Cleaner model, perhaps?
Yes, that's the idea. The benefits are less methods for Node.java, everything can be done through the Map interface, which delegates through the cache itself. The cache provides the configuration and access to the nodes, all the operations (CRUD) happen with the Nodes themselves.
My thought was:interface Node { ConcurrentMap<Object key, Object value> getData(); Fqn getFqn(); ConcurrentMap<Object name, Node n> getChildren(); Node createChild(Fqn name); // factory method // SPI etc. }
So, calling Node.getData().putIfAbsent("x", "y"); would call through the caching layer. The difficulty you will run into is the interceptor chain itself would need a separate interface to deal with the in-memory (non-delegate) version. You would probably want to have a separate interface, something like "InternalNode" or "ManagedNode":// In-memory state interface InternalNode extends Node { Map getInternalData(); Map getInternalChildren(); }
This might be part of the "SPI". -
29. Re: Designing Habanero - Cache and Node interfaces and JSR-1
-1 on all 4; I don't see why we cannot use an SPI interface for this. Let's add a discussion of the 2.0 APIs to our agenda for Vegas (although I believe it is already there)