I have an architecture which comprises the following:
HTML calling a JSP which calls an EJB(GatewayBean - we have named it as such for our
reference) all these 3 components located on 1 Application Server located in a diff. place
This bean does a remote look up of another Stateless Session EJB located on a diff.
Application Server in a diff. location. This bean then calls the DB class to retrieve the
data which is then returned back to the EJB on the first App. Server which is then used by
the JSP to diplay results.
My problem is that if the result set returned is say of more than the number of records
which can be displayed on a page at one time, then how do I save additional these records
for further reference? As the bean i'm using is Stateless Session Bean, so each time the
user wants to query for the records which cannot be displayed on first instance then the
whole process would be repeated which means additional & unnecessary DBase calls.
I have a sloution to it:
Add a Stateful Session Bean on the first App. Server which is called by the JSP. This
Stateful bean does the lookup for GatewayBean which dores the remote lookup of the Stateless
Bean & so on. The data returned is passed & stored in the Stateful Session Bean for use.
Is it the right way to do it?
The approach which you have used is one of the standard approaches.
You however, still need to answer the following question:
What if some body changes the database, the "copy" of which is being kept in your Stateful bean. If such scenario arises, the data which you are showing to the user will not be in-sync to the data which is actually there in the database !!!
The other standard approach is to make a "clone" of the object which needs to be displayed on the various screens but this approach also may not work if the intermediate data changes.
While designing/developing a similar 4-5 tier project, I faced the similar problem but I relied more on the Accuracy as compared to performance (as we can buy better servers from Vendors but we can not buy application accuracy from any vendor!!!:-)). What I did was to store the "pointer" of the data which needs to be displayed on the screen. The pointer is the starting count of the data of the screen and I stored it as a "hidden" variable in the JSP page. As the number of the rows which needs to be displayed on the screen is fixed at any time, we will always get a "fresh" copy of the data from the database.
Email: neerajgupta at india dot infogain dot com
One alternative is to store your client data in JNDI (sort of COM+ way).
Could u please explain how can I store my client-data in JNDI
Store client data in a directory using JNDI. Client will have to pass it's id to the stateless session bean to locate it's data.
The solution is really dependent on how isolated you want your transaction to be from other transactions.
Let me know and we can discuss further.
How about this approach
1. Return CachedRowSet for Stateless Bean, then using the JSP to manupulate the display of differnet page view.
2. Since CachedRowSet is disconnent Rowset, you could not be able to get refresh data form DB Server. Unless you have to requiry the data again.
I'm with Mickey on this.
1) You could the data (CachedRowSet) in the session/application context of the servet/jsp tier
2) If you requery every time, then it defeats the purpose of storing the data, I believe you are looking to store the data to avoid requerying right?