james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ahmed Mohombe <amoho...@yahoo.com>
Subject Re: Working towards a release
Date Tue, 08 Nov 2005 09:28:41 GMT
> 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
I think they would be more than happy to help (since this could be a prestige 'powered by'
project) :).


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message