Has anyone used EJB architecture for implementing an
order matching system? Order matching is used in a
marketplace system where a large number of offers to
buy and sell come in, and the system needs to match
buy and sell orders based on several attributes. The
current model I'm using is a memory based model which
contains all of the open orders, and a "matching
algorithm" is run against this data set in memory. In
EJB I could see each of the orders being modeled as an
entity bean, and the matching algorithm implemented as
a stateless session bean. The problem, I see would be
the performance penalty required to get all the open
order, iterate through them, and perform matching
logic. I would really need, I think, to cache the list
of open orders some how, but how does ejb handle this?
To keep the system tolerant of crashes, all that is
needed to persist, is the orders as they come into the
system, and the matches that have been made.
Currently, (outside of ejb), I can handle the avoiding
of duplicate matches being made by trapping the bad
match while trying to persist it to the DB. The
problem can be split up logically (different types of
instruments to match on) so scaling horizontally is
not an issue since it can be done based on creating
partitioned markets on different machines.
Current architecture (so far) involves a message que
for orders, in memory matching system, persistence of
open orders as they come into the system, persistence
of matches as they occur.
Any ideas? similiar problems solved with ejb?
-Darren
__________________________________________________
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
