[rules-users] Working memory - database synchronisation approach

[Stephen Masters]

Aha! From that explanation, it sounds like the problem is that the unit test itself has been marked as transactional, rather than just the database update. It also sounds a bit like you're managing the entity persistence from inside the entities themselves, which is likely to cause troubles if you're passing them on to a separate thread.

I would recommend going with your idea of creating a Spring service with a method marked as transactional, which will perform the actual database update.

Also, it would probably be better to keep your knowledge base outside the entities. I keep my entities simple, holding mostly properties which are to be persisted (and maybe a few transient properties). I also maintain references to entity managers outside the entities (in @Repository beans). I hold references to my knowledge sessions in a Spring @Service bean, which makes the calls to the repositories to get entities, and inserts/updates them into the session(s). It's good to have clean separation of concerns. :)

Steve


On 28 Mar 2013, at 12:06, riri <irina.adam at gmail.com> wrote:

> Thank you very much for the quick replies!
> 
> I would very much like to avoid having persistence in my rules but I am not
> sure how to get notified of changes of an object inside the working memory
> so that the service to update it can be called outside the
> WorkingMemoryEventListener. 
> 
> What I have now is a User entity that has a field which is a
> KnowledgeEnvironment. This object is a plain POJO (not Spring bean) that
> holds a reference to a KnowledgeAgent and a StatefulKnowledgeSession and has
> a method to start a new Thread with fireUntilHalt (and other methods to
> create the agent and the session). If I call this method from a unit test
> that is marked with @Transactional and have a delay in the thread execution,
> the changes get persisted to the database. Without the delay I get an
> exception 
> 
> Caused by: bitronix.tm.internal.BitronixSystemException: cannot start a new
> transaction, transaction manager is shutting down
> 
> I imagine this is because the thread is trying to execute after the
> transactional context of the unit test has been closed. I do not fully
> understand how having access to the Spring context in the separate thread
> could help me. Again, I do think that the way I am doing this is flawed
> since I need some way to keep the transaction context open so that the
> updates can be performed but I have very little experience in the matter.
> Should I have a Spring service that is marked with Transactional and can be
> called using a KnowledgeSession to span a new thread instead of the method
> inside the KnowledgeEnvironment? 
> 
> Any insight is highly appreciated!
> 
> 
> 
> --
> View this message in context: http://drools.46999.n3.nabble.com/Working-memory-database-synchronisation-approach-tp4023094p4023100.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users