L2 cache does not support distributed server about datanucleus-cache HOT 8 CLOSED

In which case you look at classes org.datanucleus.store.query.Query and/or org.datanucleus.ExecutionContextImpl#getObjectFromLevel2Cache and look at one of those classes making sure that the "Class" is initialised, USING THE ClassLoaderResolver (part of the ExecutionContext).

The only other thing to note from the second stack trace is that when performing a query, depending on the query executed I would expect the candidate class of the query to be "initialised" at that point, in which case the class will be registered with the EnhancementHelper. You provide no definition of the query or class so no comment possible on that situation.

Also note that current codebase (master) is where any proposed changes need to be, since that is what is developed.

from datanucleus-cache.

I think the reason is that it only uses objectid to get l2cache and do not check whether this 'class' has been registered or not. Here is what I found in the source:

// ExecutionContextImpl.java

Level2Cache l2Cache = nucCtx.getLevel2Cache();
CachedPC cachedPC = l2Cache.get(id);
if (cachedPC != null)
{
// Create active version of cached object with ObjectProvider connected and same id
ObjectProvider op = nucCtx.getObjectProviderFactory().newForCachedPC(this, id, cachedPC);

// ObjectProviderFactoryImpl.java

public ObjectProvider newForCachedPC(ExecutionContext ec, Object id, CachedPC cachedPC)
{
AbstractClassMetaData cmd = ec.getMetaDataManager().getMetaDataForClass(cachedPC.getObjectClass(), ec.getClassLoaderResolver());
ObjectProvider op = getObjectProvider(ec, cmd);
op.initialiseForCachedPC(cachedPC, id);
return op;
}

// StateManagerImpl.java

public void initialiseForCachedPC(CachedPC cachedPC, Object id)
{
// Create a new copy of the input object type, performing the majority of the initialisation
initialiseForHollow(id, null, cachedPC.getObjectClass());

from datanucleus-cache.

which doesnt explain what the query is being invoked, and why the candidate class is not "initialised"

from datanucleus-cache.

Here is the definition of the query from client. Any help to judge this question?

query = pm.newQuery(MRoleMap.class, "principalName == t1 && principalType == t2 && role.roleName == t3");
query.declareParameters("java.lang.String t1, java.lang.String t2, java.lang.String t3");
query.setUnique(true);
mRoleMember = (MRoleMap) query.executeWithArray(userName, principalType.toString(), roleName);

from datanucleus-cache.

So why isn't the MRoleMap class initialised when it goes through the query compilation etc and before it gets to processing the query result?

from datanucleus-cache.

Do you mean the candidateClass in org.datanucleus.store.query.Query should be initialized after pm.newQuery? Maybe more traces have to be printed in setCandidateClass or around compilation.getCandidateClass()

from datanucleus-cache.

I would expect the (Class)MetaData (annotations, XML) for the candidate class to be loaded, populated and initialised. The call to populate of the MetaData should call initialize on the class object, which should "register" it. You will see usage of "cmd" in the query objects, that is the MetaData for the candidate class. The log also tells you when metadata is loaded.

from datanucleus-cache.

Closing since no testcase provided, and no apparent willingness to develop a fix for whatever is being seen. Post back here with testcase and/or pull request as required and this can be reopened

from datanucleus-cache.