CacheListener events for state transfer marshalling

[brian.stansberry]

There's no CacheListener event generated before a node is about to be marshalled for state transfer.

Use case for this is EJB3 SFSB, where we are storing a bean context in the cache. EJB3 spec says we should invoke any prePassivate/postActivate callbacks the bean declares when we serialize/deserialize. These callbacks allow the bean to clean up it's state.

There are 3 types of serialization involved: replication, serialization to disk as part of eviction/passivation, and state transfer. The first is easy for the EJB3/JBC integration layer, as it causes the replication. The second we handle during the CacheListener callbacks. But we have no hook to handle the third.

This is kind of a specialized case, but then again maybe not. We have events for all the other significant stuff that happens to a node, except this one.

[manik]

Wow, this is a pretty specialised case. And I can't say I entirely like such a specialised call back in the listener, although I can't think of an alternative way of achieving the same. I presume you need this in 1.4.1 though, for AS 4.2?

Also, as an FYI, the way the marshalling works in 2.0.0 for ST is that a List of NodeData objects is passed to the VAM. I suppose the callbacks could happen before and after generating each NodeData object in a loop.

[manik]

And would the callback be for every node being marshalled for ST, or the fqn representing the region/subroot?

[brian.stansberry]

No, I don't think I want this for 1.4.1.SP1. I think I can use something like this:

1) Call prePassivate before caching any context.
2) Call postActivate after getting any context (to hand out to a request).

That means the context will be in the passivated state when state transfer occurs.

Whether in 2.0 having an event anyway makes sense, I still think it does, as it's a pretty major operation to happen to a node (bigger IMHO than a visit) and we emit callbacks for everything. But I don't feel at all strongly about it. How about this -- if you (or anyone) think it's really bad, veto it and we're done. :-) If you don't think it's that bad an idea, I'll open an unassigned JIRA for Beta2. If someone (aka Brian) gets it done, fine. If not, we WON'T_FIX the JIRA. Feature prioritization. :)

[brian.stansberry]

I was too wishy-washy above. I meant: "No, I don't want this for 1.4.1.SP1".

[manik]

:-) Ok, if that's the case then I will veto it for 2.0.0. I was just concerned that you did not have any other way to be compliant with the EJB3 spec. Since you do, I'd rather not have this callback.

I think this is a very specific callback (region being marshalled for ST) and is very implementation/release specific, and only will be of use to very few applications/use cases.

[genman]

Wouldn't it be possible to create your own state transfer wrapper that intercepted this?

Actually don't see any APIs that allow you to customize this..