xandrr
asked on
database bean access data return
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.
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.
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?
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?
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?
check the DbConnectionBroker out:
http://www.javaexchange.com/
http://www.javaexchange.com/
ASKER
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
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.
ASKER
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?
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.
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.
ASKER
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.