PojoCache physical POJO field mapping and region

[ben.wang]

Currently, PojoCache 2.0 uses a "flat-space" mapping approach where the user-specified id stores only a "PojoReference" where in turn it refers to the internal workspace under /__JBossInternal__.

This will present some issues when marshalling and eviction are activated (individually) where both involved in a defition of a "Region". In this case, a logical region would comprise of the user-specified id and the internal workspace.

So I am proposing to use "flat-space" per region mapping. That is, when I detect a region is present, say, "/person", then if a user calls attach("/person/joe", pojo), the internal mapping will be like:

/person
 /joe
 (key, PojoReference)
 /__JBossInternal__
 /sdaj4343xxxx
 (key, pojo)

such that the JBossInternal will be located under "/person" region. In this way, the eviction, marshalling, and even partial state transfer will be transparent from PojoCache point of view.

Note:

1. If there is no region found, it will fall back to the global workspace.
2. POJO relationship is maintained only within the region. That is, if joe and mary has the same address. Both joe and mary needs to be located under the same region. I think this is a logical assumption though.

What do people think?

[brian.stansberry]

It would be good if when I call getChildrenNames() the resulting set doesn't include _JBossInternal_. Having that exposed to user code as a child is the only downside I see to what you propose.

[genman]

Why couldn't you create a node wrapper and hang your meta data from it?

class DelegatingNode implements Node {
 Node delegate;
 ...
}

class PojoNode extends DelegatingNode {
 Object secretData;
}

Or...

There's a couple of internal cache fields, such as TreeCache.UNINITALIZED, etc. Rather than be strings, perhaps they could be typed using an interface and hidden from the user.

Maybe create a partitioning map wrapper that delegates to the ConcurrentHashMap or whatever, and has "secret" storage for internal data.

[ben.wang]

It would be good if when I call getChildrenNames() the resulting set doesn't include _JBossInternal_. Having that exposed to user code as a child is the only downside I see to what you propose.

I know you have told me before but what exactly is the usage for getChildrenNames() again? I mean can PojoCache provide that kind of functionality such that you don't need to use the underlying cache API?

[ben.wang]

"genman" wrote:

Why couldn't you create a node wrapper and hang your meta data from it?

class DelegatingNode implements Node {
 Node delegate;
 ...
}

class PojoNode extends DelegatingNode {
 Object secretData;
}

Or...

There's a couple of internal cache fields, such as TreeCache.UNINITALIZED, etc. Rather than be strings, perhaps they could be typed using an interface and hidden from the user.

Maybe create a partitioning map wrapper that delegates to the ConcurrentHashMap or whatever, and has "secret" storage for internal data.

This is certainly interesting to hide the internal fields from the users. But this will involve the underlying Cache design change either with a new API. Or if we access it directly, how do we go through the cache interceptor chain?

I have created a Jira to diiscuss it:
http://jira.jboss.com/jira/browse/JBCACHE-797

Thanks,

-Ben

[brian.stansberry]

It would be good if when I call getChildrenNames() the resulting set doesn't include _JBossInternal_. Having that exposed to user code as a child is the only downside I see to what you propose.

I know you have told me before but what exactly is the usage for getChildrenNames() again? I mean can PojoCache provide that kind of functionality such that you don't need to use the underlying cache API?

The specific use case it the root of the region is the root of the webapp; the children are the sessions. A call to getChildrenNames() provides the ids of all the sessions in the cache.

That's the specific case, but I think it's a general problem. Node higher in the tree defines some category; children represent specific instances. I think a general solution of some sort (e.g. like Elias mentions) is appropriate.

As a sophisticated user I can of course get around this by removing _JBossInternal_ from the set. But that's a hack.

You could provide some kind of PojoCache function to replace the getChildrenNames() call, but the usage here is really a plain cache usage.