qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carl Trieloff <cctriel...@redhat.com>
Subject Re: persistence
Date Fri, 08 Sep 2006 16:00:57 GMT

I would this we should keep the current pluggable interface and create a 
module for each of the 3 listed below, My
interest would be JDBC and ANIS SQL. Not sure about O/R but if someone 
wants to do O/R that is great.

This brings me to another topic, getting a roadmap up on the wiki. I 
will start another thread for this.


Joyce, Sean (Sam) wrote:
> Hi Marnie,
> Yep, that's what I had in mind. As long as we can change the poersistence backend without
having to recompile any code etc. I'll be happy :)
> I guess that the various language implementations should take an approach that is natural
to them, as long as we keep the concepts similiar it should aid all in the long run.
> regards,
> Sam.
>> -----Original Message-----
>> From: marnie.mccormack@jpmorgan.com
>> [mailto:marnie.mccormack@jpmorgan.com]
>> Sent: 08 September 2006 16:02
>> To: qpid-dev@incubator.apache.org
>> Cc: aconway@redhat.com; qpid-dev@incubator.apache.org
>> Subject: RE: persistence
>> I think it looks like we need to provide three options for users:
>> - 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\)" <Sam.Joyce@iona.com>
>> 08/09/2006 15:47
>> Please respond to qpid-dev
>>         To:     <qpid-dev@incubator.apache.org>, <aconway@redhat.com>
>>         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:aconway@redhat.com]
>>> Sent: 08 September 2006 15:28
>>> To: qpid-dev@incubator.apache.org
>>> 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.

View raw message