Cannot resolve Java bean identifier after intermediate timer

i have a flowable implementation composed by multiple process engine, one for each tenant, connected to different databases. In each process engine a map with the java beans is registered using this method processEngineConfiguration.setBeans(beanMap). My process seems to work fine, except for the behaviour after intermediate timer element. In fact the service task after timer sometimes fails with PropertyNotFoundException: Cannot resolve identifier ‘myBean’; apparently there is no pattern behind this behaviour. Note that myBean is successfully used in other service task before timer.
The following is an example of the process bit in wich the issue occurs

<serviceTask id="sid-ABF45805-9906-47B2-9657-3398B8E37880" name="Task 1" flowable:expression="#{myBean.myMethod(execution)}"></serviceTask>
<sequenceFlow id="sid-7E192F5F-DE47-49CF-B018-59A8FE21D119" sourceRef="sid-ABF45805-9906-47B2-9657-3398B8E37880" targetRef="sid-9AE29DEB-E293-4B91-8599-6D495BCC521F"></sequenceFlow>
<intermediateCatchEvent id="sid-9AE29DEB-E293-4B91-8599-6D495BCC521F" name="Timer">
<sequenceFlow id="sid-89735143-87A9-4895-9D91-D77983FBA179" sourceRef="sid-9AE29DEB-E293-4B91-8599-6D495BCC521F" targetRef="sid-7BE22367-F631-4FE9-ACD6-9B6429BBC27D"></sequenceFlow>
<serviceTask id="sid-7BE22367-F631-4FE9-ACD6-9B6429BBC27D" name="Task 2" flowable:expression="#{myBean.myMethod(execution)}"></serviceTask>

Task 1 always complete successfully, Task 2 often present the issue.

To solve this issue i’ve attach to the timer an execution listener with the classpath of my java class that implements ExecutionListener, that re-register the bean map into the specific process engine. Also this solution sometimes works and sometimes not, thowing java.lang.ClassNotFoundException.
I’m aware that this is not the best way to implement multitenancy but i don’t understand why this issue occasionally occurs

In the end, I discovered that the problem was related to the database instance. I wasn’t able to find out what actually caused the problem, but with a new database instance, it seems to be resolved.