This is a known problem on Derby. If this happens inside a paginated
list, here is a workaround (that needs to be ported to the adapter at
some point) :
((IncrementalFaultList) list).setMaxFetchSize(1000);
// 1000 is just a random #, you'll need to play with this parameter to
optimize it
// default is 10000.
Thanks,
Andrus
On Sep 12, 2008, at 10:50 AM, Øyvind Harboe wrote:
> I've got an obscure bug in our app that is caused by a stack
> overflow with Derby.
>
> The problem is that 'OR' is implemented recursively inside Derby, so
> when using ExpressionFactoyr.inExp() w/a *long* list, the stack
> overflows.
>
>
> Can this be worked around in the Cayenne Derby adapter?
>
> Should it?
>
> Ideally I'd like to see it worked around in the Cayenne Derby
> adapter and
> fixed in Derby I guess.
>
>
> # Caused by: java.lang.StackOverflowError
> # org.apache.derby.impl.sql.compile.OrNode.bindExpression(Unknown
> Source)
> #
> org
> .apache
> .derby.impl.sql.compile.BinaryOperatorNode.bindExpression(Unknown
> Source)
> #
> org
> .apache
> .derby
> .impl.sql.compile.BinaryLogicalOperatorNode.bindExpression(Unknown
> Source)
> # org.apache.derby.impl.sql.compile.OrNode.bindExpression(Unknown
> Source)
> #
> org
> .apache
> .derby.impl.sql.compile.BinaryOperatorNode.bindExpression(Unknown
> Source)
> #
> org
> .apache
> .derby
> .impl.sql.compile.BinaryLogicalOperatorNode.bindExpression(Unknown
> Source)
> # org.apache.derby.impl.sql.compile.OrNode.bindExpression(Unknown
> Source)
> #
> org
> .apache
> .derby.impl.sql.compile.BinaryOperatorNode.bindExpression(Unknown
> Source)
> #
> org
> .apache
> .derby
> .impl.sql.compile.BinaryLogicalOperatorNode.bindExpression(Unknown
> Source)
>
>
> --
> Øyvind Harboe
> http://www.zylin.com/zy1000.html
> ARM7 ARM9 XScale Cortex
> JTAG debugger and flash programmer
>
This archive was generated by hypermail 2.0.0 : Fri Sep 12 2008 - 04:23:41 EDT