As always with performance you should profile that, but I assume that
the parsing of the script creates overhead, you also has to transfer
more data.
Maybe you can also create a disk-based DB and use the disk file
directly. If you think I/O performance matter for you small db, you can
e.g. use the shm device on linux to directly operate in-memory. This
also would reduce your overall memory footprint.
About CFX: shouldn multipart do the trick?
http://cxf.apache.org/docs/jax-rs-multiparts.html
Beside this, for testing purpose, you can always start with a base64 or
otherwhise encoded String of binarry data, even if this doubles the
datasize it should be even less than a text based scripted DB.
Am 01.01.2014 16:38, schrieb Rob Oaks:
Is this what you are suggesting:
1.
Using H2 in IMDB mode, create the sub-database (defined above)
and populate it using queries against the parent database (SQL
Server). NOTE: While I could use H2 in persistent mode,
performance would certainly suffer.
2.
Use *BACKUP TO 'subdb.zip'* to create a ZIP backup of the
database (does *BACKUP TO* work in IMDB mode?).
3.
Send *subdb.zip* to ActiveMQ (via Web Service).
If this is indeed the approach you are suggesting, note that the only
difference between your suggestion and mine from the H2 perspective,
is that I am using *SCRIPT* to serialize the entire sub-database as a
string (no direct disk I/O), while you are using *BACKUP TO* to save
the sub-database as a ZIP.
Considering the small size of the sub-database (less than 100K) is
*BACKUP TO *significantly more efficient than *SCRIPT*? This is an
important question because, while this could certainly be changed, the
current messaging subsystem—built on top of CXF (in JAX-RS mode) and
ActiveMQ—does not support /attachments/ (CXF’s terminology), so
there’s some incentive to stay with string-based messaging.
String-based messaging is also a bit easier from a debugging
perspective (since I can directly log and inspect the message).
I am intrigued by your suggestion, and certainly want to do the best
thing architecturally, but I still need to be convinced that the
benefits are substantial.
Thanks so much for your perspective.
On Wednesday, January 1, 2014 7:49:23 AM UTC-5, Christoph Läubrich wrote:
What is the point of converting the DB to a String? Why not
transfer the DB file itself to the other side? ActiveMQ can handle
binary messages to as well as webservices so this seems
overcomplicated.
Am 01.01.2014 02:24, schrieb Rob Oaks:
I am not yet an H2 user, but I�m thinking H2 IMDB may be an
excellent solution in the following context:
�
*
Populate an H2 IMDB from the results of a set of queries
against a conventional database (typically SQL Server) on
the */on-premise server/*. Note that the amount of data
generated will never be more than about a 100 Kb.
*
Programmatically use H2�s SCRIPT command to create a
string representation of the entire database.
*
Send that string via Web Service to our cloud server ,
which sends that string to a message queue (ActiveMQ).
*
Our platform retrieves the string and uses H2�S RUNSCRIPT
command to recreate the H2 IMDB on our cloud server.
*
Execute queries against the H2 IMDB.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/groups/opt_out.
