I have another question (actually a few) about the appropriate
J2EE pattern/implamentation...
We have the concept of a limit order book in our trading application. That is, a list of standing orders. A stock might be trading for $43 a share, and you can put in a standing order to sell 100 shares if it ever reaches $45 per share. Effectively, this is a big table: user, stock, quantity, price, buy/sell.
Clearly this information needs to be stored on the server, so there's a single place to aggregate the information to find orders to cross (cross = a buy order and sell order which meet the needs of the other). However this information must be displayed on the client, so users can see what limit orders exist in the system. Note that this information is never persisted to the database (except possibly for crash recovery purposes). This only exists while trading is allowed, and when trading is not allowed, all limit orders are canceled.
The way I'm thinking of doing this is as follows. The server maintains an entity bean that holds all limit orders. As this limit order book is updated, notifications are sent to the client using JMS. The client then updates a local, but effectively independent (very loosely coupled) version of the limit order book. Occasionally (maybe once every 5 minutes) we may sync them up, but we're expecting regular updates to occur every few seconds. If occasional updates are lost, it's not big deal. We'll just sync to make sure things don't get too out of whack. Ultimately, the sever's information will be considered more accurate then the client's.
The alternative is to use a Value Object for the entity bean. However, given the frequency of the updates, and the high cost of getting a VO, this doesn't seem appropriate. Plus, a VO is immutable, so I'd probably have to duplicate the data locally and update it, anyway, unless I want to be getting a new VO every few seconds. This doesn't feel right.
So does it make sense to duplicate the data as first described, coupled through JMS?
--Mark