• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Mirroring Server Data

 
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think you're describing the Distributed Cache Update Pattern. See my description at http://www.messagingpatterns.com.
Kyle
 
Mark Herschberg
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yep, that's pretty lose to it, so it looks like this gets the Kyle Brown seal of approval? the only difference we have is that we will be updating the cache through messages. I think this should be ok, since we've effectively updating small table entries. Also, we are somewhat tolerant of limited partial data loss in the caches.
Does this also mean that if I had done this 12 months ago, I could've gotten a conference paper out of it? Damn.

--Mark
PS The link has an extra "." after the "com" so it goes to the wrong URL.
 
Mark Herschberg
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've got a followup question. So we're going to use the Distributed Cache Update Pattern. The entity bean on the server, what should it look like....
Let's suppose we have an object Foo, that is a wrapper for a few primatives. On the client, I have some type of container object that has an underlying array (or hashtable, etc) holding any instances of Foo. on the server, I should have a FooEntityBean, in which I would have one isntance of that bean for each instance of Foo on the client.
It seems wrong to have to create two version of the Foo class, one for the client and one for the server. If I change the fields in one, i may forget to do it for the other. Would it make more sense to have my FooEntityBean contain an instance of the class Foo, so a change to the underlying class is reflected in both the client and server code? This seems right from a maintainence standpoint, but wrong from an Entity EJB design point of view. In some cases the Entity beans will related to actual DB values, in other cases, the values are temporary (but on the order of hours) in that they are never written to the DB; does this effect the answer?
--Mark
 
Kyle Brown
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The things on the client are called value objects (as per Core J2EE Patterns) or Data Transfer Objects (as per Martin Fowler's new book). And yes, you really do need both classes.
Kyle
 
ice is for people that are not already cool. Chill with this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic