Tracking whether nodes are in-memory vs persisted

[brian.stansberry]

In 2.0 I don't see any way to determine whether a node exists in memory vs is passivated. In 1.x you can deduce this kind of thing by calling getChildrenNames() on the parent and then invoking exists() on the children. There's no equivalent API in 2.0.

This is a problem with session passivation, where the session manager is controlling evictions. It needs to know how many sessions are in memory so it can decide whether to passivate sessions or allow creation of new ones. I can track cache changes easily enough after the manager starts, but I have no way to readily determine the initial state of things when a new node joins an already running cluster.

Any ideas?

[manik]

getChildrenNames() on parent + NodeSPI#isDataLoaded() on each child node?

[brian.stansberry]

That's cheating!!!

Although I can cheat if need be. :-)

[manik]

Why is that cheating? isDataLoaded() specifically tells you whether data for a node is loaded in memory or has been evicted/passivated. Isn't that specifically what you want?

[brian.stansberry]

Casting to NodeSPI from the application is cheating.

[genman]

I thought Node should have had a "getNodeSPI" because: 1. Casts are almost always considered "cheating" and 2. Allows for creating a separate object for handling the SPI functionality. 3. Allows for some sort of proxy-security functionality. (Though if the user can cast the Node to NodeSPI, so much for security.)

[manik]

Well, the separate-object-proxy approach can prevent people from cheating; I guess the real question here is whether the NodeSPI is intended for use by application code at all, or just by plugin/extension authors. My leaning is towards the latter, which means that if something is isDataLoaded() is needed by application code, then it should be promoted to the Node interface.