I think it looks like we need to provide three options for users: - ANIS SQL - JDBC - O/R
.. and let them choose the appropriate plug-in. I'm not sure how else to wrap the persistence ? Regards, Marnie JPMorgan Chase BLAZE (QPID) Integration Developer https://confluence.uk.jpmorgan.com/confluence/display/IBTAMQ/Blaze "Joyce, Sean \(Sam\)" <[EMAIL PROTECTED]> 08/09/2006 15:47 Please respond to qpid-dev To: <[email protected]>, <[EMAIL PROTECTED]> cc: Subject: RE: persistence Hi Folks, I think we do need a *thin* layer around the persistence API's and I don't think that layer should be JDBC (for Java). My reasoning is that while most people will likely be using a real database for the persistence of messages I can think of several use-cases where there is no actual database in use. E.g. an N-safe replicated in-memory database with async spooling to hard storage. Or, in the presence of a reliable, high-speed, distributed shared file system, a check-pointed local file would be sufficient. I would prefer that we not force people (us) to use JDBC directly from within the Qpid code base. I have a very string aversion to hard coding SQL statements in code. I've had quite a bit of experience (past life) accessing different databases from code and while the standard SQL is most common databases if almost exactly the same it is still only *almost* exactly the same :) So I would propose that the persistence API not be database specific. I do believe we can achieve this without having to sacrifice performance too much, but *any* message persistence is going to affect performance is some way wrt transient messages. Note also, that when we are designing this persistence layer we need to be mindful of reason for having a persistence layer at all i.e. reliability and recoverability in the face of apparent disaster :) therefore having to take a hit (performance wise) to do a full recovery vs. not affecting performance (too much) for the normal error-free code path. Whether we use an o/r mapping layer or not is not something I have strong feelings about as long as can achieve reliability (via persistence) without affecting performance on the error-free code paths. Given that the data model for the kind of persistence we are looking at is not large, I thing we should be able to achieve it with some ease :) Regards, Sam. > -----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++ :) This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
