A while back I spec'ed out an interface for a MessageStore as a generic JMS message store to improve on the JMS store I have in Hermes. It never got past the interface stage and is incomplete but hey.
The idea was that it was a hierarchy of regions containing queues. The implementaion could then map those regions to different tables or even databases on the server or if it was not an SQL implementation then memory mapped files or whatever. In the following code, you'd have to imagine the JMS message was an AMQMessage and the destination some kind of internal AMQ queue. You can ignore the idea of messages having an index, that was to support replay and is not relevant. http://hermesjms.cvs.sourceforge.net/hermesjms/MessageStore/source/java/herm es/store/ I like the idea of regions - in QPID an exchange could have its own region. Anyway, I thought it may be something useful to share... Regards, Colin. http://hermesjms.com -----Original Message----- From: Alan Conway [mailto:[EMAIL PROTECTED] Sent: 08 September 2006 15:28 To: [email protected] Subject: Re: persistence On Fri, 2006-09-08 at 09:56 -0400, Rajith Attapattu wrote: > I agree with Rafeal, and we need to have a very simple persistant API. > But then again O/R mappers are in style and end users may prefer > things like hibernate, ibatis etc.. > And they maybe convinent to work with. People will definitely want to change the DB backend, but I predict that no Qpid user will ever care *how* we get the data into the database, they will only care: - Can I use my favorite database X? - Is it fast? I'm guessing JDBC is all the pluggability we need, so the only reason to use an O/R mapper is if we think it's a productivity win for us and it doesn't have significant performance impact. I don't think the Qpid persistence schemas are going to be very complex so I'm not sure a O/R mapper gives us much, but I don't know the Java ones well enough to comment further. 'nuff said, back to C++ :)
