I've seen the same problem with updating via the CachedRowSet, but had
been blaming MySQL's lack of transaction support (with the default
tables at least).
As a workaround, I'm using PreparedStatements for update/insert/delete
but drawing the data from the RowSets to avoid defining another
structure.
Have had no problems whatsoever with selects at least.
There are plans to increase support within Struts for RowSets in the
1.1. timeframe. (Who knows, maybe we can do a FastCachedRowSet that can
cope with inserts!) In the meantime, I'm wrapping the Rowsets in
standard beans and Iterators so I can use what we got now with what we
got now. Hopefully I can just drop the wrappers later and use the raw
Rowsets.
Obviously, I'm extremely interested in your work, and would love to see
it.
Speaking of configuration issues, I've also played with the idea of
loading SQL commands from a resource, so they could be changed and
reloaded without restarting the application. It would also be easier to
optimize command sets for different DBMS packages. Just wondering if
anyone else has implemented a SQL command resource.
"Gogineni, Pratima" wrote:
>
> Hi Ted,
>
> I remember playing with cached rowsets sometime ago. It is probably useful
> to standardize your tags/code etc. based on the cached rowset rather than
> create your own data-structure - but I found that particularly the
> update/delete/insert into the rowset doesnt work properly for all but the
> simplest tables.
>
> I am currently implementing my own web-app(struts-based) that could handle
> more cases - one thing with this is that the user can specify the
> update/insert/delete in an xml file to configure my rowset - since I think
> it is not possible to anticipate in all cases what statements they would
> want to use. This also allows them to fire off multiple statements (for
> data-integrity reasons or something else) in a transaction for each of the
> actions update/insert/delete ...
>
> Pratima
