[
https://issues.apache.org/jira/browse/DERBY-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546793
]
Kathey Marsden commented on DERBY-1482:
---------------------------------------
I came across this relevant comment in DMLWriteResultSet and thought I would
post for reference.
/* We only need to objectify the streams here if they are exposed to the users
through the
* trigger context. For "before" trigger, we could just return
the stream wrapped in
* RememberBytesInputStream to the user and reset it after
usage, but this wouldn't work
* because the user may get the stream in trigger action and do
something with it in parallel
* with the store doing insert. We could also delay the
materializing until the stream is
* fetched in before trigger but that would complicate the
code. For "after" trigger, we have
* to materialize it here because store only keeps a page's
amount for each round. For other
* reasons of "deferred" operations we don't need to objectify
here. Simply going through a
* temp table (either in memory part or spilled to disk) is
fine for the stream, unless a
* same stream appears in two rows in the temp table, which
could happen for an "update", in
* which case we do the objectifying in UpdateResultSet.
Beetle 4896. Related bug entries:
* 2432, 3383.
*/
> Update triggers on tables with blob columns stream blobs into memory even
> when the blobs are not referenced/accessed.
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1482
> URL: https://issues.apache.org/jira/browse/DERBY-1482
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.2.1.6
> Reporter: Daniel John Debrunner
> Priority: Minor
>
> Suppose I have 1) a table "t1" with blob data in it, and 2) an UPDATE trigger
> "tr1" defined on that table, where the triggered-SQL-action for "tr1" does
> NOT reference any of the blob columns in the table. [ Note that this is
> different from DERBY-438 because DERBY-438 deals with triggers that _do_
> reference the blob column(s), whereas this issue deals with triggers that do
> _not_ reference the blob columns--but I think they're related, so I'm
> creating this as subtask to 438 ]. In such a case, if the trigger is fired,
> the blob data will be streamed into memory and thus consume JVM heap, even
> though it (the blob data) is never actually referenced/accessed by the
> trigger statement.
> For example, suppose we have the following DDL:
> create table t1 (id int, status smallint, bl blob(2G));
> create table t2 (id int, updated int default 0);
> create trigger tr1 after update of status on t1 referencing new as n_row
> for each row mode db2sql update t2 set updated = updated + 1 where t2.id =
> n_row.id;
> Then if t1 and t2 both have data and we make a call to:
> update t1 set status = 3;
> the trigger tr1 will fire, which will cause the blob column in t1 to be
> streamed into memory for each row affected by the trigger. The result is
> that, if the blob data is large, we end up using a lot of JVM memory when we
> really shouldn't have to (at least, in _theory_ we shouldn't have to...).
> Ideally, Derby could figure out whether or not the blob column is referenced,
> and avoid streaming the lob into memory whenever possible (hence this is
> probably more of an "enhancement" request than a bug)...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
