I'm only an observer on this list but I'd recommend looking at HOWL as a high speed way to asynchonously spool state into a relational database (or other store). This is probably easier to do now rather than later given the recovery implications.
http://howl.objectweb.org/ Also, FWIW (as I say I am only an observer!) it may be better to shy away from any O/R layer and keep as close to the database as you can. No doubt the abstractions you'll put in place however will give you a multitude of options for how to map to the final store, its these interfaces that would be good to stabalise now. Regards, Colin. http://hermesjms.com -----Original Message----- From: Frank Lynch [mailto:[EMAIL PROTECTED] Sent: 06 September 2006 21:30 To: [email protected] Subject: persistence I'd like to start working on a persistence solution for Qpid that will be compatible with our apache licensed implementation. I've been thinking about iBatis + Derby for this. I like the flexibility that iBatis brings, as it allows users to tweak the database table format/schema if necessary and its easy to slot in an enterprise strength database (like Oracle, Sybase etc) in leiu of Derby. Has anyone any opinions or thoughts on this, or should I just start hacking away at an iBatis based persistence implementation? cheers, --Frank
