Design decisions

Discussions

EJB design: Design decisions

  1. Design decisions (7 messages)

    Hi All,

    Before asking my questions. I'd like to briefly describe the current project and redisgin.

    The project that I'm working for is real/near time finantial application. It is a 2-tier app. Front - Swing, back - Sybase 12.5, MOM - TIBCO publishing to DB. Here is the flow. TIBCO inserts records to DB, client refreshes the views every 10 sec. The data is mostly for display. The app evolves with time and now we are getting more and more data, and number of users is growing too. Now we started to notice some perf. problems with bottleneck in the DB (every user has its on db connection querying the database every 10 sec). I cannot use cashing because the data is changing very often (TIBCO).

    Here is the decision I made:

    1. Since the data is for display only, I would use JDBC for Reading pattern(Floyd Marinescu) to retrieve the data from the database. Since I'm using JTable on the client I can return RowSet for each view(Data Transfer RowSet pattern).

    2. Message Facade to publish the RowSetDataObject to the client. This eliminates each client poling the db every 10 sec.

    3. I need to create something on the app server side (BEA WL)
    to query the db every 10 sec and create RowSetDataObject. This way the server will query the db once and publish the RowSetDataObject objects to everybody.

    Finally, I have 2 questions.

    Will the design work?
    What is the best way to the functionality described in the 3 item?

    Thanks for taking time to read the long post.

    Leonid

    Threaded Messages (7)

  2. Design decisions[ Go to top ]

    Hi,
    As I understood the TIBCO is publishing the messages on a queue. Some process consumes messages from the queue and inserts them in the DB for future refference. If the queue would be turned into a topic the application server and/or the swing client could consume messages from the topic. So you could make a mechanism that reads the 'fresh' data directly from the topic, in order to eliminate the DB reads bottleneck. I think the change from the queue approach to a topic approach won't be very hard to do.
     
    Best regards, Mircea
  3. Design decisions[ Go to top ]

    Hi,

    I'd love to do it, but we are not using TIBCO JMS, instead we are using
    TIBCO Randevouz. There is no queues the message is published to all subscribers right away.


    Thank you for your time.


    Leonid
  4. Design decisions[ Go to top ]

    The component in your application that is writing to the DB can also publish on a Tibco RV which all your clients can listen on (using TibrvListener IIRC). All your clients would require an RV daemon to be installed but it is much more desirable than making 'n' connections to your database all querying the exact same row(s) of data.

    Take a look at these classes.
    com.tibco.tibrv.Tibrv;
    com.tibco.tibrv.TibrvException;
    com.tibco.tibrv.TibrvListener;
    com.tibco.tibrv.TibrvMsg;
    com.tibco.tibrv.TibrvMsgCallback;
    com.tibco.tibrv.TibrvRvdTransport;
    com.tibco.tibrv.TibrvTransport;

    Tibco's Rendezvous product is very popular in financial circles as a mechanism for broadcasting realtime information to multiple clients. We use it here for our trade floor applications.
  5. Design decisions[ Go to top ]

    For your point number 3, perhaps you could use timer service (from ejb2.1 onwards)
  6. Design decisions[ Go to top ]

    I thought aboutit. I think WL 8.1 has this service, but somehow I thought it was useful only for monitoring the WL evironment.

    Can I use it with any other java class?

    Thank you for your time
  7. do not rule out cache[ Go to top ]

    I would not rule out caching more so when there is a noticed performance problem. There are many caching mechanisms, think of refreshing the cache whenever there is a row update, how many concurrent users do you have?
  8. do not rule out cache[ Go to top ]

    At this phase of the project we have 50 users total and 10 concurrent.

    Thanks you for your time.

    Leonid