Re: [rules-users] Working memory - database synchronisation approach
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(a)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...
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users