Menu
▾
▴
jboss-dev-forums
|
From: <ben...@jb...> - 2006-06-16 05:58:00
|
This is a sample usage that I can envision: | PojoCache cache = PojoCacheFactory.getInstnace(PojoConfig); | | Person p = new Person(); | String id = "/person/p"); | | cache.attach(id, p); | | Person p1 = (Person)cache.find(id); | | cache.detach(p); | or | cache.detach(id); | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3951220#3951220 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3951220 |
|
From: <ben...@jb...> - 2006-06-16 06:06:26
|
Finally, I am thinking the underlying PojoCacheImpl will implement both PojoCache and Cache API such that: | pulbic class PojoCacheImpl implements PojoCache, Cache | and to switch between PojoCache and Cache interface, you can do like: | PojoCache pc = PojoCacheFactory(PojoCacheConfig); | | pc.attach(pojo); | ... | | // Switch to plain Cache | | Cache c = (Cache)pc; | c.put(fqn, blah, blah); | True that to use plain Cache, you will need to cast it explicitly. But I don't see the frequent usage of Cache api under PojoCache anyway so I think this present a clear separation of interfaces. What do people think? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3951222#3951222 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3951222 |
|
From: genman <do-...@jb...> - 2006-06-16 17:20:09
|
I would keep them as separate APIs. Having both seems like it would add lots of methods that you shouldn't be accessing directly. Something like this would be interesting: | TreeCache cacheInstance = ...; | PojoCache cache = PojoCacheFactory.getInstance(pojoConfig, cacheInstance); | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3951358#3951358 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3951358 |
|
From: <ben...@jb...> - 2006-06-18 23:04:14
|
are you saying that we should have two separate cache isntances? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3951549#3951549 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3951549 |
|
From: <man...@jb...> - 2006-06-20 13:16:16
|
No, but since PojoCache will use delegation to the cache instance, the cache instance could be passed in to the factory. I agree with genman that implementing both interfaces will add a lot of clutter. Perhaps even having a PojoCache.getCache() method to return the underlying Cache may be an option. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3951975#3951975 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3951975 |
|
From: <ben...@jb...> - 2006-06-20 14:06:26
|
Yeah, I think the issue basically boils down to whether we will have two separate configuration files for PojoCache (PC) and JBossCache (JBC) or not. It has pros and cons. 1. Have two separate configs, | Cache cache = CacheFactory(cacheConfig); | PojoCache pc = PojoCacheFactory(pojoCacheConfig, cache); | 2. Just one config containing both JBC and PC, | PojoCache pc = PojoCacheFactory(config); | Cache cache = pc.getCache(); | I prefer the second one but what do people think? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3951998#3951998 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3951998 |
|
From: <man...@jb...> - 2006-06-20 14:22:29
|
Even in the case of the first one, it would look like: | Cache cache = CacheFactory.getInstance(configFile); | PojoCache pc = PojoCacheFactory.getInstance(cache); | There are no pojocache specific configurations in the config file, are there? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3952006#3952006 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3952006 |
|
From: <man...@jb...> - 2006-06-20 14:22:51
|
I'm happy with either approach though. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3952008#3952008 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3952008 |
|
From: <ben...@jb...> - 2006-06-20 14:40:56
|
Actually, there are additional configurations now for PojoCache and I forsee there will be more in the future. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3952016#3952016 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3952016 |
|
From: <man...@jb...> - 2006-06-20 14:45:34
|
ok, lets stick to PojoCache.getCache() then ... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3952018#3952018 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3952018 |
|
From: <ben...@jb...> - 2006-06-21 06:16:54
|
Another thing that I want to point out is that now we don't require to specify a Fqn that is associated directly with the underlying Cache. Instead, a String id is required. This has pros and cons that I can see: Cons - Since we still map Id internally to Fqn, if the id is without separator, e.g., "/justThis", then concurrency is not optimial since everything works from the root. As a result, we need to ask the user to have separator in the Id string. Not very natural. Pros - It decouples from the Fqn of which is more accurate since a user should only cares about the Id of the Pojo. Semantically, this is a much better one. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3952226#3952226 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3952226 |
|
From: <man...@jb...> - 2006-06-21 10:14:59
|
Possibly a very silly idea, but how about creating subtrees for the ids internally?
E.g.,
id ("TEST") => Fqn (/T/TE/TEST)
id ("TELEVISION") => Fqn (/T/TE/TELEVISION)
id ("COUCH_POTATO") => Fqn (/C/CO/COUCH_POTATO)
id ("A") => Fqn (/A/A)
Like I said, possibly a silly idea ...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3952290#3952290
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3952290
|
|
From: <gal...@jb...> - 2006-06-21 18:52:56
|
Ben, why would PojoCacheImpl need to implement Cache? Would it be so that clients could work on it from the Cache interface? Or is it to take advantage of some common actions? I personally don't see the need for it to implement Cache, but maybe there's something I'm missing... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3952462#3952462 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3952462 |
|
From: <gal...@jb...> - 2006-06-21 18:55:55
|
I guess semantically, a PojoCache is a Cache so it'd make sense, but as manik said, it'd clutter the implementation of PojoCache. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3952463#3952463 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3952463 |
|
From: <gal...@jb...> - 2006-06-21 21:58:40
|
I think delegation between PojoCache and Cache would stll work better. However, the configuration side would be tricky as mentioned earlier. If the config was passed to both PojoCache and Cache, we would like to avoid any double processing. I guess PojoCache would only look at the configuration relevant to it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3952490#3952490 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3952490 |
|
From: <ben...@jb...> - 2006-06-22 01:28:36
|
"man...@jb..." wrote : Possibly a very silly idea, but how about creating subtrees for the ids internally?
|
| E.g.,
|
| id ("TEST") => Fqn (/T/TE/TEST)
| id ("TELEVISION") => Fqn (/T/TE/TELEVISION)
| id ("COUCH_POTATO") => Fqn (/C/CO/COUCH_POTATO)
| id ("A") => Fqn (/A/A)
|
| Like I said, possibly a silly idea ...
|
|
This is certainly interesting.
Another way is to hash the user id first, e.g.,
id("TEST") => Fqn("hash(TEST)", "TEST")
if I don't detect a "/".
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3952520#3952520
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3952520
|
|
From: <ben...@jb...> - 2006-06-22 01:32:32
|
A PojoCache impl will need to have Cache implementation as well one way or the other. This is such that a user may need to revert back to the plain old Cache api (like get()). Here is what I have in mind: | PojoCache pc = PojoCacheFactory.createInstance(config); | pc.attach(id, pojo); | | ... | | // Obtain the underlying cache impl. | Cache cache = pc.getCache(); | cache.put(...); | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3952521#3952521 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3952521 |
|
From: <ben...@jb...> - 2006-06-29 07:53:46
|
Manik, not sure if TransactionTable has it. But can the Cache SPI also expose the underlying transaction manager or the underlying tx if there is any? Use case in PojoCache is I need to know during attach or detach if there is ongoing tx. If not, I will need to start one for the batch processing purpose. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954269#3954269 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954269 |
|
From: <man...@jb...> - 2006-06-29 16:11:41
|
Look at Interceptor.getInvocationContext().getTransaction() View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954427#3954427 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954427 |
|
From: <ben...@jb...> - 2006-06-30 01:35:07
|
And how do I get an Interceptor instance? From getInterceptorChain and take any of the Interceptor? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954555#3954555 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954555 |
|
From: <man...@jb...> - 2006-06-30 16:47:17
|
yeah, thats how it is in 1.4, which is crap. in 2.0.0, I'm going to add a static call on InvocationContext to get the current context. So you'd just do: InvocationContext.getCurrentContext() which returns an instance of the current invocation context. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954704#3954704 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954704 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X