3:46 a.m.
Hello everyone,
I am currently working on a Spring, Hibernate, Bitronix project and am
trying to integrate Drools functionality. I have a set of JPA Entities that
I can manage using Spring Data and Hibernate and I would like to use these
entities as facts inside a StatefulKnowledgeSession. As I understand it, I
need to have some mechanism of keeping the facts inside the working memory
in sync with the database and what I mean by that is:
1. update the facts in working memory when they are changed from outside
2. update the facts in the database when a RHS part of a rule changes
properties
This article http://www.ibm.com/developerworks/java/library/j-drools5/
<http://www.ibm.com/developerworks/java/library/j-drools5/> gives some
pointers on how to achieve 1. using AOP but in my case I do not have a
global knowledge session to insert, I need to be able to create a knowledge
base for each user of the application since each user will need to have his
own set of rules independent from other users.
What would be the best practices for achieving the synchronisation?
Currently for 1. I am updating the fact manually by retrieving the object
and calling update from java code. For 2. I have a
WorkingMemoryEventListener that is configured as a Spring @Component with
autowired services that can perform CRUD actions on entities and which are
called on objectUpdated.
I am new to all these technologies so I do not know if this is a good way to
go. I have a unit test where a rule modifies a property and the object is
updated in the database but if the Thread with the fireUntilHalt method is
not paused, the test finishes and the JTA manager is shut down before the
rules can fire and the transaction in the objectUpdated can be executed.
I would be very grateful for any insight from the more experienced users
that have come across such requirements before.
Best regards
--
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.
5:17 a.m.
That sounds like a decent design to me. I don't much like having persistence inside
the rules.
The issue you have seems more related to the fact that you're executing the rules in a
separate thread than your persistence design. I don't suppose you're actually
spawning a thread from inside a JTA transaction in which to run your rules?
Steve
On 28 Mar 2013, at 08:46, riri <irina.adam(a)gmail.com> wrote:
Hello everyone,
I am currently working on a Spring, Hibernate, Bitronix project and am
trying to integrate Drools functionality. I have a set of JPA Entities that
I can manage using Spring Data and Hibernate and I would like to use these
entities as facts inside a StatefulKnowledgeSession. As I understand it, I
need to have some mechanism of keeping the facts inside the working memory
in sync with the database and what I mean by that is:
1. update the facts in working memory when they are changed from outside
2. update the facts in the database when a RHS part of a rule changes
properties
This article http://www.ibm.com/developerworks/java/library/j-drools5/
<http://www.ibm.com/developerworks/java/library/j-drools5/> gives some
pointers on how to achieve 1. using AOP but in my case I do not have a
global knowledge session to insert, I need to be able to create a knowledge
base for each user of the application since each user will need to have his
own set of rules independent from other users.
What would be the best practices for achieving the synchronisation?
Currently for 1. I am updating the fact manually by retrieving the object
and calling update from java code. For 2. I have a
WorkingMemoryEventListener that is configured as a Spring @Component with
autowired services that can perform CRUD actions on entities and which are
called on objectUpdated.
I am new to all these technologies so I do not know if this is a good way to
go. I have a unit test where a rule modifies a property and the object is
updated in the database but if the Thread with the fireUntilHalt method is
not paused, the test finishes and the JTA manager is shut down before the
rules can fire and the transaction in the objectUpdated can be executed.
I would be very grateful for any insight from the more experienced users
that have come across such requirements before.
Best regards
--
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
6:08 a.m.
fyi - There may be simpler/cleaner ways of doing it, but if you wish to ensure that you
always have access to your Spring context even when you're out roaming on a separate
thread, you can get static access to the context like this below. I use it so that I can
use Spring to help me get data for Guvnor enums:
/**
* Maintains a static reference to a Spring {@link ApplicationContext}, and a
* static getContext() method, which will initialize the context if necessary.
*
* @author Stephen Masters
*/
public class GuvnorEnumContext {
private static ApplicationContext ctx = null;
GuvnorEnumContext() {
}
GuvnorEnumContext(ApplicationContext applicationContext) {
ctx = applicationContext;
}
public static ApplicationContext getContext() {
if (ctx == null) {
ctx = new AnnotationConfigApplicationContext(GuvnorEnumConfig.class);
}
return ctx;
}
}
/**
* Due to the fashion in which Guvnor enums are invoked, we maintain a
* static reference to the Spring {@link ApplicationContext} in the
* {@link GuvnorEnumContext}. This ensures that the context is only instantiated
* once.
*/
private static MyFinder finder() {
return (MyFinder) GuvnorEnumContext.getContext().getBean("myFinder");
}
On 28 Mar 2013, at 10:17, Stephen Masters <stephen.masters(a)me.com> wrote:
That sounds like a decent design to me. I don't much like having
persistence inside the rules.
The issue you have seems more related to the fact that you're executing the rules in
a separate thread than your persistence design. I don't suppose you're actually
spawning a thread from inside a JTA transaction in which to run your rules?
Steve
On 28 Mar 2013, at 08:46, riri <irina.adam(a)gmail.com> wrote:
> Hello everyone,
>
> I am currently working on a Spring, Hibernate, Bitronix project and am
> trying to integrate Drools functionality. I have a set of JPA Entities that
> I can manage using Spring Data and Hibernate and I would like to use these
> entities as facts inside a StatefulKnowledgeSession. As I understand it, I
> need to have some mechanism of keeping the facts inside the working memory
> in sync with the database and what I mean by that is:
> 1. update the facts in working memory when they are changed from outside
> 2. update the facts in the database when a RHS part of a rule changes
> properties
>
> This article http://www.ibm.com/developerworks/java/library/j-drools5/
> <http://www.ibm.com/developerworks/java/library/j-drools5/> gives some
> pointers on how to achieve 1. using AOP but in my case I do not have a
> global knowledge session to insert, I need to be able to create a knowledge
> base for each user of the application since each user will need to have his
> own set of rules independent from other users.
>
> What would be the best practices for achieving the synchronisation?
> Currently for 1. I am updating the fact manually by retrieving the object
> and calling update from java code. For 2. I have a
> WorkingMemoryEventListener that is configured as a Spring @Component with
> autowired services that can perform CRUD actions on entities and which are
> called on objectUpdated.
>
> I am new to all these technologies so I do not know if this is a good way to
> go. I have a unit test where a rule modifies a property and the object is
> updated in the database but if the Thread with the fireUntilHalt method is
> not paused, the test finishes and the JTA manager is shut down before the
> rules can fire and the transaction in the objectUpdated can be executed.
>
> I would be very grateful for any insight from the more experienced users
> that have come across such requirements before.
>
> Best regards
>
>
>
> --
> 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
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
7:06 a.m.
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.
7:43 a.m.
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
10:26 a.m.
I may not have explained the architecture I have very well so here it is: I
have plain JPA entities, some of which I want to insert as facts in the
working memory, all entities have repositories defined for them via the
Spring Data JpaRepository and these repositories are called by Spring
Services whenever I need to retrieve, save, delete an entity from the
database. This works well on its own, the methods in the services are all
marked as transactional via AOP pointcuts in the Spring configuration file,
but I want to be able to persist the changes made to an entity from the
working memory to the database and for that I thought about calling the
Spring services inside the WorkingMemoryEventListener.
I think the problem might be with the way I call the fireUntilHalt() method
in a separate thread and the fact that the transaction manager is shut down
at the end of the test, before the entities have time to be updated in the
database. In my test I have 2 rules and the first rule makes modifications
to an entity that trigger the second one. The modifications from the first
rule are saved, the second rule gets triggered but the transaction manager
and the spring context are closed before the update can be made for the
entities in the second rule. Would this be a problem related to the test
itself since in normal functioning the spring application and the
transaction manager would be open unless the whole application is shut down?
I will try and do some more tests to see how to solve this even though I am
not sure if what I am doing is the right way to go. Thank you for the
insight Steve!
--
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.
4261
days inactive
4261
days old
5 comments
2 participants
participants (2)
-
riri -
Stephen Masters