Mike Matrigali wrote:
Oystein Grovlen - Sun Norway wrote:
Mike Matrigali wrote:
> What is the expected usage pattern for an update on a clob that uses
these "temporary" clobs? What is the usual input format, what is the
usual output format? Do you expect more than one update usually? Does
an update have to rewrite the end of the file on and shrink or expand of
a middle of the clob?
In client/server, a single update may cause a sequence of updates
against the embedded driver. This is because the locator
implementation uses a stored procedure to perform the update, and
Derby does not support Clob as procedure parameters. To overcome
that, the Blob is split into segments of max size for VARCHAR. Hence,
it is important at the overhead of positioning is not big in these
cases. One way to optimize for this would be to remember the end
position from last write.
How do these calls relate to calls to the store code for the update? Is
there still one call to store or one per segment?
The calls work on a temporary copy of the Blob. Store is affected when:
1) ResultSet.updateRow is a called and the Blob is a column in the
result set.
2) PreparedStatement.execute is called and the Blob is a parameter.
At that point the Blob is streamed into Store the same way as before.
--
Øystein
