Question about serverside ValidationContext exception

[Blama]

Hi Isomorphic,

using v12.1p_2022-08-10 and before 12.0p I have been getting this exception for a long time.
Do you have an idea what might be going wrong here?

LoggerName
com.isomorphic.datasource.ValidationContext

Message:
Freeing cached DataSource instances from ValidationContext::finalize() - these should have been freed on-thread with a manual call to freeResources(). The stack that created the ValidationContext is:

Stack trace:
java.lang.Exception
    at com.isomorphic.datasource.ValidationContext.<init>(ValidationContext.java:81)
    at com.isomorphic.rpc.RPCManager.iframeWrite(RPCManager.java:2404)
    at com.isomorphic.rpc.RPCManager.completeResponse(RPCManager.java:2079)
    at com.isomorphic.rpc.RPCManager.send(RPCManager.java:760)
    at com.isomorphic.servlet.IDACall.processRPCTransaction(IDACall.java:183)
    at com.lmscompany.lms.server.LMSIDACall.processRequest(LMSIDACall.java:49)
    at com.isomorphic.servlet.IDACall._processRequest(IDACall.java:119)
    at com.isomorphic.servlet.IDACall.doPost(IDACall.java:79)
...
...

Thank you & Best regards
Blama

[Isomorphic]

This may indicate that you are doing DSRequests outside of the automatic management & freeing of resources controlled by RPCManager. If you do a DSRequest and do not associate it with an RPCManager, you need to call freeAllResources() to efficiently free resources. Otherwise the resources will only be reclaimed after a delay, where garbage collection occurs.

See Standalone DataSource Usage for more information.

[Blama]

Hi Isomorphic,

thanks, that helps and I identified one location where this might happen.
Am I understanding it correct, that this is only something I have to do myself in a Standalone DataSource Usage case, where I also use DSTransaction.rollback() or DSTransaction.commit(), not when I'm only using DSRequest.execute()? In the latter case this is managed by the framework.

Best regards
Blama

[Isomorphic]

In addition to the mentioned help topic, also take a look at the help for DSRequest.freeAllResources(), where it's specified exactly when it must be called.

[Blama]

Hi Isomorphic,

thanks. Reading the DSRequest.freeAllResources() docs it seems that this does not apply to me. Specifically point 3 does not apply (the others do).
I'll try with the call after the spot where I use commit()/rollback() nevertheless. Perhaps it helps, at least is does not seem to make things worse in my local testing.
But as I do not leak connections here (confirmed by checking DB connections when this piece of code is called multiple times), I don't think this is the issue.
Do you have an other idea for the root cause of the exception?




Regarding the DSRequest.freeAllResources() docs:
You say

You have not called setRPCManager() on the request, AND

and then

Regarding 2), it would be normal practice to call setRPCManager() or setDSTransaction() on server-created DSRequests because this is required in order to participate in automatically managed transactions.

The 2nd sentence makes it sound like using setDSTransaction() (but not setRPCManager()) would be enough to mitigate the need for freeAllResources().
Is this correct? And if so, doesn't make this the 1st sentence incomplete?
Shouldn't it then be something along the lines of:

You have not called setRPCManager() and also not called setDSTransaction() on the request, AND

Regarding the Standalone DataSource Usage docs:
It says:

If you do not want SmartClient Server's default behavior of automatically rolling back if any DSRequest failed, you can manually take over the transaction management by calling commit() or rollback() instead of complete(). Note, if you do this you also take on responsibility for releasing the database connection by calling freeQueueResources() or freeAllResources(). If you fail to do this, you will leak database connections

Doesn't this contradict the freeAllResources() docs, where it says that I have this responsibility only sometimes?


Thank you & Best regards
Blama

[thaleszop]

I have a Custom Validator that checks if a field value exists in a database table (if so then the validation is true), debugging the code actually does the validation roblox toy codes mobdro

[Isomorphic]

Hi Isomorphic,

thanks. Reading the DSRequest.freeAllResources() docs it seems that this does not apply to me. Specifically point 3 does not apply (the others do).
I'll try with the call after the spot where I use commit()/rollback() nevertheless. Perhaps it helps, at least is does not seem to make things worse in my local testing.
But as I do not leak connections here (confirmed by checking DB connections when this piece of code is called multiple times), I don't think this is the issue.
Do you have an other idea for the root cause of the exception?

Have you tried temporarily disabling any server-side custom request or transaction processing to see whether the issue is no longer reported? That should help isolate the origin.

Regarding the DSRequest.freeAllResources() docs:
You say

and then


The 2nd sentence makes it sound like using setDSTransaction() (but not setRPCManager()) would be enough to mitigate the need for freeAllResources().
Is this correct? And if so, doesn't make this the 1st sentence incomplete?
Shouldn't it then be something along the lines of:

If setDSTransaction() is called on the requests, but they're not associated with an RPCManager, then the only cleanup done for you is if/when DSTransaction.complete() is called with a "true" argument, requesting that resources be freed. So the two cases are not identical.

Regarding the Standalone DataSource Usage docs:
It says:


Doesn't this contradict the freeAllResources() docs, where it says that I have this responsibility only sometimes?

The assumption in that help topic is likely already that you're creating and manging your own DSRequests, i.e. that bullets 1, 2, and 3 from freeAllResources() apply. So that's why, if you don't call DSTransaction.complete(), which takes a freeResources argument, you must call DSTransaction.freeQueueResources() yourself.

[Blama]

Hi Isomorphic,

If setDSTransaction() is called on the requests, but they're not associated with an RPCManager, then the only cleanup done for you is if/when DSTransaction.complete() is called with a "true" argument, requesting that resources be freed. So the two cases are not identical.

Thanks, that is my situation.
So if all three bullet points apply, I'm responsible to call freeAllResources().
I'm not calling that, but also I don't fulfill the 3rd bullet point, so in theory I should be fine. Nevertheless I get these exceptions.
My problem is that I only see them in my prod logs, not on my machine when testing.
Is there any problem with calling freeAllResources() myself after DSTransaction.commit()? Because if not, I'd give that a try and look if the exceptions are still happening.

Best regards
Blama

[claudiobosticco]

Hello, I'm following this thread, and I'm a bit worried as I've never called DSTransaction.complete() with a true argument, simply because...it isn't documented.
https://smartclient.com/smartclient-...tml#complete--

But maybe it's the default?

[Isomorphic]

Hello, I'm following this thread, and I'm a bit worried as I've never called DSTransaction.complete() with a true argument, simply because...it isn't documented.
https://smartclient.com/smartclient-...tml#complete--

But maybe it's the default?

The no-argument version of DSTransaction complete() indeed cleans up the transaction's resources, as the Javadoc states. So you should be OK.

Good catch about the other method signature. It hasn't been exposed externally yet, though it is a public function. So currently we don't support an official way to call complete() without cleaning up - though if you call commit() yourself instead of complete() that will then require a separate call to freeAllResources().

Hi Isomorphic,

Thanks, that is my situation.
So if all three bullet points apply, I'm responsible to call freeAllResources().
I'm not calling that, but also I don't fulfill the 3rd bullet point, so in theory I should be fine. Nevertheless I get these exceptions.
My problem is that I only see them in my prod logs, not on my machine when testing.
Is there any problem with calling freeAllResources() myself after DSTransaction.commit()? Because if not, I'd give that a try and look if the exceptions are still happening.

As the other poster noticed, if you're calling complete() with no arguments, which is the only public signature, then no additional cleanup is needed. However, if you're calling commit() yourself and not complete(), then yes, you'll want to call freeAllResources() too. Note that freeAllResources() tracks internal state, so calling it multiple times (perhaps unintentionally) should not cause a problem.