This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Hello All, I'd like to develop an application that would exist of an applet which contains a JTable that presents a view into a database, and a servlet which would act as a proxy for the applet and run queries on the database for the applet. In the environment where this would run the applet isn't allowed to talk directly to the database. In the case of a select I'd like to pass the servlet my query as a string and then return the resulting rowset back to the applet, is this possible? I've built a little example where the servlet takes the data out of the rowset and builds a comma seperated string and sends that to the applet but I could eliminate 1 level of processing if I could just return the rowset. Ideas?? Thanx Dave
The most important thing to understand is that a network connection is a "serial" interface, so to transfer an object from one device to another over a network it needs to somehow be "serialized" at the sending end, and reconstructed at the receieving end. If an object contains a reference to another object, then both objects must be serialized and sent, together with an indication of which object is referenced. Just sending a chunk of raw memory is unlikely to make any sense at the other end. It's more tricky than it seems There are a lot of choices for how you do this, though. Some are built in to the standard Java APIs (e.g basic object serialization), there are plenty produced by third parties, and you can always write your own (as you have already done, effectively). In your case I suggest that returning a RowSet "directly" using the built-in object serialization would not be a particularly good idea. Typically RowSet and ResultSet objects are closely tied to the database, and sometimes don't actually fetch each row data from the database until you ask for it. In particular note that RowSet is an interface, so you are completely dependent on how the author of your particular database driver chose to write the implementation. A better choice might be to fetch all your data from the RowSet into a more stable form (a list of arrays, for example), and then send that. For this you can use the built-in object serialization, but I'd also recommend that you look at some of the light-weight alternatives such as hessian from caucho.com. I hope some of this has helped.
Hi Frank, You're exactly right Overnight I managed to write code to do what I described but at runtime I got an "object not serializable" exception when I tried to write the resultset back to the applet. I tried to do it like this java.io.ObjectOutputStream out = new java.io.ObjectOutputStream(response.getOutputStream()); String str = "select * from my_table"; out.writeObject(doSelect(str )); where the doSelect function executes the query and return the resultset. As I said I'm trying to avoid doing some kind of data transformation here as in the past it has proven to be a source of possible errors/bugs. I think I'll investigate transforming the resultset into xml, aren't there some whiz/bang tools for doing that? Thanx Dave
Joined: Jan 07, 1999
I'm trying to avoid doing some kind of data transformation here as in the past it has proven to be a source of possible errors/bugs. I think I'll investigate transforming the resultset into xml Personally, I think XML is not particularly appropriate for tabular data. It imposes a significant overhead in data size, bandwidth use, and processor time to compose and parse it. And I think thay if you are not careful you will have all the same "possible errors/bugs" that you are worried about. Just like CSV, XML has delimiters, so you will need to worry about possible '<' and '&' characters in your data, for example. Please reconsider loading the data from the RowSet into something simple and compact like a List of arrays, then serialize it using someone else's fully tested and bullet-proof code (built-in object serialization, "hessian", etc.)