It's not a secret anymore!*
The moose likes OO, Patterns, UML and Refactoring and the fly likes discarding database roundtrips Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "discarding database roundtrips" Watch "discarding database roundtrips" New topic
Author

discarding database roundtrips

manish ahuja
Ranch Hand

Joined: Oct 23, 2003
Posts: 312
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

Joined: Jul 11, 2001
Posts: 14112
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?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
manish ahuja
Ranch Hand

Joined: Oct 23, 2003
Posts: 312
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

Joined: Apr 16, 2008
Posts: 2187
... 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

Joined: Oct 23, 2003
Posts: 312
to be precise 12 database interactions
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
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

Joined: Oct 23, 2003
Posts: 312
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

Joined: Apr 16, 2008
Posts: 2187
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

Joined: Oct 23, 2003
Posts: 312
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

Joined: Apr 16, 2008
Posts: 2187
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

Joined: Jul 11, 2001
Posts: 14112
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

Joined: Oct 23, 2003
Posts: 312
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: discarding database roundtrips