We help IT Professionals succeed at work.

database bean access data return

xandrr
xandrr asked
on
We were currently switching our architecture to java and I had a few questions regarding what a java bean should return in terms of a recordset.

One of our guys setup a bean that returns the data in a vector of objects with each row being one object. I think this is pretty inefficient, but we can't really think of a better way. What is the standard way of doing this? What should be returned. The reason we just don't return the recordset is we were running into connection isses when a jsp page required multiple recordsets to use. (the connection conflicts). Is there anything in java that is like a disconnected recordset? Can someone give me an example of this? We wanted to use J2EE MVC setup standards...servlet serving jsp and talking to java beans. What is the best way for returning data using this standard?

Thanks guys.
Comment
Watch Question

I think your best bet would be to solve your connection issues and return the ResultSet.  What problems were you having with your Connections?  What DB and which drivers are you using?  Are you pooling your connections?

Commented:
i have used the very same solution (with the vector) you described myself. though it was for a relatively lightweight app.

you're closing your connections when you're done with them right? but of course there is a lot of overhead having to open a connection everytime.

actually, i think you are ready for connection pooling.  you are most likely using JDBC 2.0. the javax.sql package contains a set of  interfaces (ConnectionEventListener, ConnectionPoolDataSource, PooledConnection) that should sort you out.

can you give us more details on the connection issues you are running into?

Commented:
check the DbConnectionBroker out:
http://www.javaexchange.com/

Author

Commented:
Basically...suppose we were looping through a recordset on the page. if in the middle of the loop through, we needed to call another recordset, we couldn't do it because the connection wouldn't allow multiple recordsets (which is why if i could somehow make a disconnected recordset that would be great - like in VB).

Also, I have a question about the vector setup you mentioned. Were there generic objects in the vector that could suit any table? Or did each table have it's own object type? I really don't like the later one that we are doing because each table change/creation requires and object change.

So basically (back to original question) I needed to know the best way to deal with data returns and outputs using that MVC architecture.

Thanks guys.
The Vector approach is bad because you are doub;e-bufferring a whole resultset.
Also, Vectors are not very efficient from a runtime perspective.  If you end up going with this approach, It would be best to write a class that inplements the ResultSet interface, but caches the objects.  I would use an Object array (you can tell how big to make it based on ResultSetMetaData) that holds ArrayLists.  You will have to do some reconsiliation based on datatypes - If you have an int value, and call getString() on the column, you have to catch this and make the appropriate conversion.  getString() and getCharacterStream() is another example where you have to manipulate the data before returning it.

It would probably easier, cleaner, and more efficient to address you connection issue - what you are experiencing is not the norm.  Instead of working around it, you should fix it.

Why are you trying to use the same connection?  Why not use a second connection when you need the second resultset?  If you pool your connections, you won't even have to deal with the Connection creation overhead.  A connectio pool should only take a few hours to implement, and it will make life a whole lot easier.


Hi,
 1. You can get the recordset in vctor.
 2. Put that vector values in helperBean(any javabean).
 3. Do manuplications Requried there.(sort..)
 4. Keep it in first index of a string array with some  
    delimiter.
 5. Get data in vector from another Recordset again.
 6. Repeat the procedure. by incrementing index of String
    array.  
 7. In Jsp Use it with StringTokenizer.

You CAN use the Vector, but it's not the correct approach.  You CAN cache the whole database in a series of Vectors and Hashmaps, but that, like the Vector approach, is wasteful and incorrect.

Author

Commented:
Yeah..I guess the main thing we were trying to accomplish was to have a way to get a disconnected recordset and the best thing the other guys on my team came up with (we're new to java) was a vector. Is there anything similar to getrows in asp? We basically wanted access to records without having an open connection for them so we could pass them around, etc.

So I guess what I'm asking is what's the best accepted way to manipulate data in an MVC web architecture?
It should be OK to pass around ResultSets, as long as you close them (and the statements) after you are done with them.  The connection issues you mentioned are not normal.  You should be able to handle multiple ResultSets on a connection, or if you are pooling them (which you probably should be doing anyway) you can grab a new connection for each quesry.  This topic really should go toward debugging your connection problem, not working on a hack to avoid the real issue.

What database are you using?  Which JDBC drivers are you using?  Are you pooling?  Are you closing your ResultSets, and Statements after you are done with them?  What happens when you try to get a second resultset while the first is still open?

The reason dumping the contents of a resultet into a vector (or another object that serves as a disconnected rs) is so bad is as follows:

1) If you are returning more than 25 or so rows, your JDBC drivers most likely are not loading the whole resultset into memory at once - it buffers a certain number of rows and when you need more, it retrieves more.  Loading the entire resultset into an object of any kind will take more time, and will use more memory.

2) Maintenence.  Every time your schema changes, you will have to address all your caching objects.

3) Speed.  Not only do you have to read the whole rs with the caching approach before you can start retrieving any data, but the Vector is a relatively slow datastructure.  It has synchronization overhead as well as it is very innefficient when accessing it's contents.

4) You are double-buffering your data, again using more memory and CPU time.

Author

Commented:
Hey guys..i guess we went with the vector implementation regardless (contractors don't have much say :) ). I'll give the points to m_onkey since he helped out a lot though.

Explore More ContentExplore courses, solutions, and other research materials related to this topic.