on 1-05-15 22.48, Damon Hart-Davis at [EMAIL PROTECTED] wrote:
> I'd like to to use the built-in Hypersonic if at all possible.
> If not, I'll put everything in an external database.
You can use it and should - I for one love it, all depending tho, for a
datastore with millions of records comprising several GB of data as You
mention below, I would run that in a separate instance, for the integrity of
the data, enabling uninterrupted uptime while separating modular maintenance
of other components existing in the system.
> 1) As I go on doing operations with CMPs (with lots of large
> Serializable objects or byte[] in the entity beans in question, in case
> that makes a difference) the
> JBoss-2.2.1_Tomcat-3.2.1/jboss/db/hypersonic/default.script file grows
> and grows, even if for example, I drop the tables. The default.data
> file never grows. How can I get the `log' flushed? Here, for example,
> id the current state of the hypersonic directory after inserting the
> same few MB of data a few times:
>
> drwxr-x--- 2 dhd ExNet 512 May 14 00:24 ./
> drwxr----- 5 dhd ExNet 512 May 10 22:51 ../
> -rw-r----- 1 dhd ExNet 12 May 14 00:24 default.backup
> -rw-r----- 1 dhd ExNet 20 May 14 00:24 default.data
> -rw-r----- 1 dhd ExNet 80 May 14 00:24 default.properties
> -rw-r----- 1 dhd ExNet 125300428 May 15 18:46 default.script
In Your properties file, the field 'modified=' says 'yes' it would mean that
the last time was not closed correctly, and repair will kick in. If the
field contains 'yes-new-files' then the "old" backup and script files are
deleted. and new "clean" ones created. If not closed correctly (crash) then
the modified field will contain 'yes' and the script file contains all info
to redo changes to the data. The data file may well then be corrupt, because
the in memory cache was not written out completely. -
hypersonicsql/doc/files.html describes it all ...
> 2) I cannot create records (entity beans), eg including largish
> Serializable objects or byte[]s, larger than about 32kBytes in total.
> Is there any way to fix that directly? At the moment I am fragmenting
> data across several entity beans, but that will make some things that I
> want to do, such as maintaining a live index in an object in a entity
> bean, usually held in memory but passivatable back to the db,
> spectacularly inefficient.
Binary data size is currently restricted to 32KB because UTF is used.
> 3) Even if I keep records shorter than 32kBytes, if I undeploy and
> redeploy the same (unchanged) EAR, on trying to read some entity beans
> back into memory, they are reported as corrupt, `not containing
> serializable data' in some ByteArray deserialisation routine inside
> Hypersonic itself I think. This means I usually have to reload lots of
> data each time I make even the most minor change to my EAR, which is
> very sad. All data is loaded through Java with no access by anyone
> else.
se 1
> 4) I intend to have several GB of data in my database in the end, with
> several tables/beans having up to millions of records each. Will that
> completely stuff Hypersonic?
Hypersonic is Hypersonic, Informix is Informix, Informix and the like has
indexes of indexes to speed things up, + more maintanance tools.
A "in memory" Hypersonic instance together with a "mirrored hot switched"
separate "in memory" instance of Hypersonic ... would get U a lot of "bang
for the buck" ... ;-)
> I am resigned to having to sort some of these problems by moving to a
> different DB, but I want at least to understand what's going on with
> Hypersonic and make it a little more robust and to last as long as
> possible.
While developing, use a separate instance to avoid corrupting the db when
"finding undocumented features" in Your JBoss configuration.
/peter
> Regards,
>
> Damon
>
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
