[rules-users] [droolsflow] Code-based constraints for EventWait nodes - is this possible?

[Alan.Gairey at tessella.com]

Kris,

After posting my last question, I quickly came to the same conclusion as 
you, so I'm now using a rule-based constraint in my EventWait node.

This however has presented a different problem. If I create my session 
from JPAKnowledgeService, then when I try to insert my fact into the 
session, I get the following error:

bitronix.tm.internal.BitronixRollbackException: transaction was marked as 
rollback only and has been rolled back
        at 
bitronix.tm.BitronixTransaction.commit(BitronixTransaction.java:153)
        at 
bitronix.tm.BitronixTransactionManager.commit(BitronixTransactionManager.java:96)
        at 
org.drools.persistence.session.SingleSessionCommandService.execute(SingleSessionCommandService.java:258)
        at 
org.drools.command.impl.CommandBasedStatefulKnowledgeSession.insert(CommandBasedStatefulKnowledgeSession.java:305)
(Everything works fine if I create my session from the knowledge base - 
i.e. with no state persistence.)
Prior to using a rule-based constraint (with no call to 
CommandBasedStatefulKnowledgeSession.insert), the session created from 
JPAKnowledgeService worked OK.
I'm using the default JPA configuration from the Drools documentation 
(persisting to H2 database, etc.).
Any ideas what might be causing the problem?
Many thanks,
Alan




Kris Verlaenen <kris.verlaenen at cs.kuleuven.be> 
23/10/2009 03:00

To
Rules Users List <rules-users at lists.jboss.org>, Alan.Gairey at tessella.com
cc
Rules Users List <rules-users at lists.jboss.org>
Subject
Re: [rules-users] [droolsflow] Code-based constraints for EventWait nodes 
- is this possible?






No, the constraint of an EventWait node (or the State node in Drools
5.1) can only be rule-based.  The reason for this is that the rule
engine knows when to re-evaluates rules (based on the evailable input).
 If you would use a code-based constraint, the engine would have no idea
when this code constraint might become true (if it was false at the
start).  Only constant re-evaluation of the code constraint could
achieve this (which would be tremendously inefficient).  Could you
explain why you would like to have this behaviour?  Maybe there is an
alternative way to model this.

To change the value of a variable from inside the process (using an
action), simply use kcontext.setVariable(name, value).  We do not
recommend manually changing the value of a process variable from outside
the engine.  Again, could you explain why you would like to have this
functionality?

Kris

Quoting Alan.Gairey at tessella.com:

> Can the constraint for an EventWait node in a flow be code-based
> (rather 
> than rule-based)? The Eclipse plug-in (v 5.0.1) doesn't allow this to
> be 
> specified, unlike say for a Split node, although the relevant XML can
> of 
> course be edited.
> Trying to load such a process flow results in a NullPointerException,
> 
> because the constraint is always interpreted as a rule.
> 
> Ideally what I'd like to do is have an EventWait node where the
> constraint 
> tests the value of a process variable. This then leads me to another
> 
> question; is there a way of setting the value of a process variable
> via 
> the Drools Flow API?
> 
> Thanks in advance for any help,
> 
> Alan
> Tessella plc
> 26 The Quadrant, Abingdon Science Park, Abingdon, Oxfordshire, OX14
> 3YS
> E: Alan.Gairey at tessella.com, T: +44 (0)1235 555511, F: +44 (0)1235
> 553301
> www.tessella.com    Registered in England No. 1466429
> 
> This message is commercial in confidence and may be privileged. It is
> 
> intended for the addressee(s) only. Access to this message by anyone
> else 
> is unauthorized and strictly prohibited. If you have received this
> message 
> in error, please inform the sender immediately. Please note that
> messages 
> sent or received by the Tessella e-mail system may be monitored and
> stored 
> in an information retrieval system.
> 




Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20091026/1f77e00e/attachment.html