Given that the whole crash starts with: java.lang.OutOfMemoryError, then
maybe that caused the problem with derby.
From the derby list, 64MB for it only looks like not enough.
Does anyone know anything about derby's behaviour when it runs out of
memory? I'd imagine that these errors are caught in any code that uses a lot
of memory (ie loading data) but what about other parts of code that arnt as
likely to cause that kind of problem?
AFAIK if it has it's own virtual machine (so it's in network mode) and if has
more than 64MB it can gracefully handle such situations. The problem is that
under
64MB it can do to much for such situations - it's like an IDE that doesn't do
well
without a minimal size :).
I know very little about derby, but i have used hsqldb before. It had
similar problems - if one instance of the driver opened a database, other
instances couldnt write to them (or read iirc).
No it's not the same. Derby is not 'full in memory' db, and it has special
fail safe functions(and recovery too).
There are however a few tips that must be followed to work efficiently (and
mostly they
do not apply on any DB - e.g. Mysql)
IMHO the best would be to setup a test system that can be reached by other
Apache
members, and than to ask kindly the authors from Derby to have a look(they are also Apache members,
right?).
I think they would be more than happy to help (since this could be a prestige
'powered by' project) :).
Ahmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
