Databases Reference
In-Depth Information
Performance considerations
In the previous example, we've been working on the basis that every time we receive
a new bid, we add it to our list of bids received and then submit the auction and the
entire list of bids to the ruleset for evaluation.
The obvious issue with this technique is that we are reevaluating all the bids that we
have received from scratch every time we receive a new bid.
One possible solution would be to have a stateful rule session. With this approach,
we would first submit the auction item to the decision service but with no bids. Then
as we receive a bid, we could assert that against the ruleset and get the updated
result back from the decision service.
The issue with this (as we discussed at the start of this chapter) is that when the
BPEL process dehydrates, which in the case of our auction process will happen
each time we wait for the next bid, the rule session is not persisted. Consequently,
whenever the server is restarted we will lose the rules session of any auction in
progress, which is clearly not desirable.
Managing state within the BPEL process
One alternative is to use the BPEL process to hold the state of the rule session. With
this technique, we need to ensure that all relevant facts contained within the rule
session are returned within the facts that the decision service is watching. The next
time we invoke the decision service, we can resubmit these facts (along with any new
facts to be evaluated) and reassert them back into a new rule session.
In the case of our auction ruleset, the relevant facts that need to be maintained
between invocations are
auctionItem
and
winningBid
, which is contained within
auctionItem
.
With this approach, each time we receive a new bid, we just need to assert the
auctionItem
element as returned by the previous invocation of the ruleset and
the new bid (within the
bids
element). As a result, each time we submit a new bid,
rather than reevaluate all bids to determine the winning bid, we just need to evaluate
the new bid against the winning bid, which is clearly more efficient.
To support this, we do not have to make any modifications to our ruleset, as we have
implemented it in such a way that it supports either asserting all bids in one go or
submitting them incrementally.
