As much as I made it clear (via earlier response) that I don't think
clients should have access to DB resources like your CallableStatement,
it is understandable that a client could very well want to display
something like a JTable with the results of a query. In which case, you
still need the data packaged up for the clients use.
Saying that, you might want to look at Sun's disconnected CachedRowSet
stuff, available here:
http://developer.java.sun.com/developer/earlyAccess/crs/
There's a great tutorial here (with an EJB example usage with *MUCH*
more sound advice than that "developerworks" example had):
http://developer.java.sun.com/developer/Books/JDBCTutorial/chapter5.html
Here's a pertinant snippet:
<snip>
public RowSet getCoffees() throws SQLException {
Connection con = null;
try {
con = ds.getConnection("managerID", "mgrPassword");
Statement stmt = con.createStatement();
ResultSet rs =
stmt.executeQuery("SELECT COF_NAME, PRICE FROM COFFEES");
CachedRowSet rset = new CachedRowSet();
crset.populate(rs);
rs.close();
stmt.close();
return crset;
} finally {
if (con != null) con.close();
}
return null;
}
</snip>
On that page, make sure you read section 5.3.2. The above CachedRowSet
is *non-updatable*. It provides a read-only copy of the data. Exactly
what responses to your original note on this email thread have been
heralding.
Hope this helps,
David
--
Per Lewau wrote:
> On Wed, 23 May 2001, Guy Rouillier wrote:
>
>
>> I also didn't read the article, but in my not so humble opinion, this is **
>> terrible ** advice. Keeping a database statement (and hence connection)
>> open for use by a client is just asking for trouble in a network
>> environment. First is the pandora's box of possible failure points in the
>> point-to-point connection. But even if you have a perfect network, you have
>> no idea what the caller is going to do with that statement. He may do
>> nothing and just sit on it for the next 3 weeks! I read the other response
>> to this post, and I don't think allow remote iteration to a collection is a
>> good idea for similar reasons. You want to design your system to maximize
>> robustness, concurrency and performance. All of these benefit from
>> finishing a logical unit of work completely in a single method before
>> returning to the client. We've opted to serialize our database results into
>> an xml string, close the db connection (which returns it to the pool) and
>> then send the xml string back to the client.
>
>
> You're absolutely right. I'll have to back down on my suggested solution
> (remote iteration). It was more of a work-around really, but you're
> right.
>
> Don't let the clients near the database.
>
> (The good thing about being rash is that hindsight comes quicker ;)
>
>
>
>
>> ----- Original Message -----
>> From: "Dave, Pragnesh" <[EMAIL PROTECTED]>
>> To: <[EMAIL PROTECTED]>
>> Sent: Wednesday, May 23, 2001 4:03 PM
>> Subject: Re: [JBoss-user] Stateless Session Bean and CallableStatement
>>
>>
>>
>>> In one the articles at developerworks, Cynthia Saracco actually says that
>>> wrapping DBMS stored proc under stateless session beans is a "good" idea
>>
>> and
>>
>>> passing the Serialized CallableStatement back to the client a better
>>> approach then creating your own Collection.
>>>
>>
>>
>> _______________________________________________
>> JBoss-user mailing list
>> [EMAIL PROTECTED]
>> http://lists.sourceforge.net/lists/listinfo/jboss-user
>>
>
>
> -----------------------------------------------------------------------
> Per Lewau ([EMAIL PROTECTED])
>
> "Why waste time learning, when ignorance is instantaneous?"
> - Hobbes
>
>
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
--
-----------------------------------------------------------------------
David Ward [EMAIL PROTECTED]
Senior Software Engineer http://www.dotech.com
Distributed Object Technologies, Inc. 716-381-8320 (phone)
500 Linden Oaks, Rochester, NY 14625 716-381-0598 (fax)
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
