I was involved in an order matching system for two different brokerage
houses,one a traditional brokerage house the other an ECN. We used an
approach similar to your in-memory idea where we kepy a copy of the book in
memory updating the actualy book in a "checkpoint" like fashion. The beans
containing the book would refresh the cache at failover when a request was
made of the book, and yet the bean found no in-memory copy of the book.
In one case we we implemented this pre-EJB 1.0 so we used a vendor
proprietary solution. In the later we did use EJB's and XA/messaging
substrates to accomplish it. I do believe that much of the same
functionality could be modelled inside of the EJB world through smart finder
caching of entities etc. But I would agree with your direction of caching
entiries in the book. The complex issue comes with when and how do you
checkpoint the cache back to persistant storage. Although stocks do get
dk'd (lost) its an unpopular situation.
Dave Wolf
Internet Applications Division
Sybase
----- Original Message -----
From: "Darren Pamatat" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, February 05, 2001 9:15 AM
Subject: Use of EJB for matching system?
> 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".
>
>
===========================================================================
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".
