Let's take a step back and ask ourselves what it is that we want to
scope ? Off of the top of my head the following things come to mind:
- HTTP sessions. I guess they're independent, so we can have a scope per
session. Do you guys currently use 1 Cache per session ? Then Galder's
suggestion below makes sense
- SFSBs: do we have 1 scope per bean ? What if bean X has a ref to bean
Y ? Would they have to have the same scope ?
- Hibernate 2LC: scope per entity ? I don't know how entities are broken
into tuples in the 2LC.
On 1/31/11 2:19 PM, Galder Zamarreño wrote:
> Hmmmm, not sure about adding a method to IC, cos that would lead to code like
> this which is very verbose:
>
> cache.getAdvancedCache().getInvocationContextContainer().getInvocationContext().setScope("X")
>
> As a user, I'd prefer something like:
>
> cache.getAdvancedCache().withScope("X")
>
> However, this would only be used to attach a particular scope. I envision a
> global, cache manager level configuration such as that marks all caches in
> that cache manager to be scoped by the cache name. That way, HTTP session
> repl code would need no changing at all and with a single flag, they could
> make each individual cache to act in its own scope. The code above would
> allow two caches to share the same scope for those situations where we want
> sequential calls for the two caches, i.e.:
>
> cache1.getAdvancedCache().withScope("X")
> cache1.put()
> cache2.getAdvancedCache().withScope("X")
> cache2.put()
>
> By the way, I don't understand your comment of "refine this scope by adding
> GlobalTransaction and so on". If we take the cache1/cache2 example and
> imagine that these two would be called within a transaction, I'd imagine that
> the transaction itself would act as a scope and so would not need for a
> particular scope definition? i.e.
>
> tx.begin()
> cache1.put()
> cache2.put()
> tx.commit()
>
> At first glance, 5.0 would be the perfect target for this, but we'd need to
> take in account for any requirements coming from Paul since HTTP session repl
> could greatly benefit from it.
>
> As far as 2LC is concerned, within a deployment multiple txs will be
> operating on same caches so scoping could not be used. However different
> deployments could benefit from deployment level scoping so that messages for
> different caches can be sent in parallel. In AS environment different
> deployments could share the same 2LC cache manager and so the configuration
> option above would not work, but I'd need a deployment level scope that I'd
> use with cache.withScope().
>
> Cheers,
>
> On Jan 28, 2011, at 8:54 PM, Vladimir Blagojevic wrote:
>
>> Forgot to mention that scopes require addition of SCOPE protocol to the
>> stack. So we can probably do this on 5.0 branch only.
>> On 11-01-28 4:52 PM, Vladimir Blagojevic wrote:
>>> Hey,
>>>
>>> JGroups scopes [1] have been implemented for a while now and we should
>>> think about using them in Infinispan. I looked around a bit to see how
>>> we can use scope and satisfy requirements Manik outlined [2]. I think a
>>> good idea would be to introduce scope method in InvocationContext? We
>>> can start by implementing scope to return hash of cache name where
>>> invocation originated and subsequently refine this scope by adding
>>> GlobalTransaction and so on. Users, if they really need to scope their
>>> calls could do so by attaching additional markers to InvocationContext
--
Bela Ban
Lead JGroups / Clustering Team
JBoss
_______________________________________________
infinispan-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
