You might also consider some sort of caching approach that would make the
second call to remoteService.getLocation() cheap.
-W
On 22 March 2012 19:45, lhorton <LHorton(a)abclegal.com> wrote:
That would be a good approach for one location. My real world rules
are 24
rules for 24 different locations. If I used your approach, I think I would
have to look up and insert all 24 locations for each session execution (we
use stateless sessions) in order to have the 24 setter rules work.
I am trying to avoid too many calls to the RMI service (remote database
reads), which is why I was trying to put all the work into the one rule
pattern. in my real-world rules, there are more conditions in the pattern
than just the RMI lookup, so that only one of the setter rules will fire
for
each session execution.
--
View this message in context:
http://drools.46999.n3.nabble.com/Can-I-capture-the-result-of-an-RMI-call...
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