-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: 08 September 2006 16:02
To: [email protected]
Cc: [EMAIL PROTECTED]; [email protected]
Subject: RE: persistence
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.
