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
-
Design decisions (7 messages)
- Posted by: Leonid Brandis
- Posted on: February 26 2004 09:35 EST
Threaded Messages (7)
- Design decisions by Mircea Crisan on February 26 2004 10:52 EST
- Design decisions by Leonid Brandis on February 26 2004 15:33 EST
- Design decisions by Wayland Chan on March 01 2004 06:04 EST
- Design decisions by Leonid Brandis on February 26 2004 15:33 EST
- Design decisions by Hari Lakshmanan on February 26 2004 11:57 EST
- Design decisions by Leonid Brandis on February 26 2004 15:39 EST
- do not rule out cache by leerutg leerutg on February 26 2004 13:56 EST
- do not rule out cache by Leonid Brandis on February 26 2004 15:35 EST
-
Design decisions[ Go to top ]
- Posted by: Mircea Crisan
- Posted on: February 26 2004 10:52 EST
- in response to Leonid Brandis
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 -
Design decisions[ Go to top ]
- Posted by: Leonid Brandis
- Posted on: February 26 2004 15:33 EST
- in response to Mircea Crisan
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 -
Design decisions[ Go to top ]
- Posted by: Wayland Chan
- Posted on: March 01 2004 18:04 EST
- in response to Leonid Brandis
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. -
Design decisions[ Go to top ]
- Posted by: Hari Lakshmanan
- Posted on: February 26 2004 11:57 EST
- in response to Leonid Brandis
For your point number 3, perhaps you could use timer service (from ejb2.1 onwards) -
Design decisions[ Go to top ]
- Posted by: Leonid Brandis
- Posted on: February 26 2004 15:39 EST
- in response to Hari Lakshmanan
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 -
do not rule out cache[ Go to top ]
- Posted by: leerutg leerutg
- Posted on: February 26 2004 13:56 EST
- in response to Leonid Brandis
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? -
do not rule out cache[ Go to top ]
- Posted by: Leonid Brandis
- Posted on: February 26 2004 15:35 EST
- in response to leerutg leerutg
At this phase of the project we have 50 users total and 10 concurrent.
Thanks you for your time.
Leonid