Win a copy of Think Java: How to Think Like a Computer Scientist this week in the Java in General forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

discarding database roundtrips

 
manish ahuja
Ranch Hand
Posts: 312
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi there,

Currently I have an application which is by its very nature is database intensive so through out the life-cycle flow the application has to frequently do a round trip to the database fetch values, persist data and again read back etc
This works fine but our client has come up with the request of completely dismantling this database roundtrip business.

I would like to know what alternative approaches are available. One that occurs to me is having some sort of an in-memory database. If any one has done some work in this direction do post your thoughts. Also in this approach what is the max data size it can hold and ultimately what strategy to use to synch up the in-memory database with the physical datastore.

Let me know your viewpoint on the same.

Regards.

Manisha
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by manish ahuja:

This works fine but our client has come up with the request of completely dismantling this database roundtrip business.


What is the motivation for that request?
 
manish ahuja
Ranch Hand
Posts: 312
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Though I don't have much idea. There is overall exercise of aligning all IT projects in the SOA direction.
I understand making our application available as a web service so other calling apps can communicate with it in a seamless fashion.
But avoiding the database roundtrip was a bit hard to digest.
Essentially the idea is each application of the client will communicate with the database world (comprising of all databases belonging to different apps) via an ESB.
But looking at the database intensive nature of our application I don't think routing via ESB makes much sense.
The vague idea I got is to fetch all data required for the app upfront do all in-memory data processing activities and then communicate back to the database via the ESB when the application is done with one logical flow.

Let me know your thoughts
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
... so through out the life-cycle flow the application has to frequently do a round trip to the database fetch values, persist data and again read back ...


How often does the application make this "round trip to the database"? One, two, five, twenty ...
[ November 06, 2008: Message edited by: James Clark ]
 
manish ahuja
Ranch Hand
Posts: 312
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
to be precise 12 database interactions
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you expose the application as a web service, will these 12 database calls be part of a single call on the web service?
 
manish ahuja
Ranch Hand
Posts: 312
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes the web service invocation is just 1 call.
The database interactions is part of the internal logic of the application.
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes the web service invocation is just 1 call.
The database interactions is part of the internal logic of the application.

So, based on this, there would be no database roundtrips between the client application and the web service.

What is the issue?
 
manish ahuja
Ranch Hand
Posts: 312
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The problem at hand is to find an alternative to avoid those database round trips which happen as part of one application flow. The idea is to reduce those multiple database interactions and have some sort of in-memory database.
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I see. Is the application and the database management system located on different machines?

An alternative to creating an object-based memory database would be reduce the number of database calls. This can be accomplished by writing more efficient SQL statements and/or using stored procedures and/or modifying the relational model.
[ November 07, 2008: Message edited by: James Clark ]
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by James Clark:

An alternative to creating an object-based memory database would be reduce the number of database calls. This can be accomplished by writing more efficient SQL statements and/or using stored procedures and/or modifying the relational model.


Another option might be caching. Frankly, I'm still not sure what the reason behind wanting to reduce database access is...
 
manish ahuja
Ranch Hand
Posts: 312
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the response.
At this juncture I am not sure whether the app and the database will be collocated or on separate machines.
Disregarding my current requirement I want to understand how widespread is the approach of using "an in-memory database". I got to hear a framework called "Seam" is step in that direction.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic