6 Replies Latest reply on Feb 4, 2007 10:56 PM by genman

CacheListener events for state transfer marshalling

brian.stansberry Feb 3, 2007 9:22 PM

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.

1. Re: CacheListener events for state transfer marshalling

manik Feb 4, 2007 6:33 AM (in response to brian.stansberry)

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.
Actions
2. Re: CacheListener events for state transfer marshalling

manik Feb 4, 2007 8:38 AM (in response to brian.stansberry)

And would the callback be for every node being marshalled for ST, or the fqn representing the region/subroot?
Actions
3. Re: CacheListener events for state transfer marshalling

brian.stansberry Feb 4, 2007 8:47 AM (in response to 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. :)
Actions
4. Re: CacheListener events for state transfer marshalling

brian.stansberry Feb 4, 2007 9:03 AM (in response to brian.stansberry)

I was too wishy-washy above. I meant: "No, I don't want this for 1.4.1.SP1".
Actions
5. Re: CacheListener events for state transfer marshalling

manik Feb 4, 2007 9:06 AM (in response to brian.stansberry)

:-) 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.
Actions
6. Re: CacheListener events for state transfer marshalling

genman Feb 4, 2007 10:56 PM (in response to brian.stansberry)

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..
Actions

Go to original post