You are viewing a plain text version of this content. The canonical link for it is here.
Posted to sandesha-dev@ws.apache.org by Thomas McKiernan <MC...@uk.ibm.com> on 2008/10/13 15:49:02 UTC
jdbc storage manager
Hi guys,
I believe this question may have been asked before but I couldn't find
anything in the archives.
I was wondering if anybody had tried implementing a persistent (e.g. JDBC)
version of the sandesha2 storage APIs?
If so can they share where they got with it, any issues they faced and
whether they committed it up to open source anywhere?
And has anyone got any other information related to this question?
Many thanks,
Thomas
----------------------------------
Thomas McKiernan
WebSphere Messaging Development,
IBM United Kingdom Limited
Internal Phone: 248241
External Phone: +44 (0)1962 818241
Mobile: +44 (0)789 1737497
Email: MCKIERNA@uk.ibm.com
Mail Point 211, IBM, Hursley Park, Winchester, Hampshire, England, SO21
2JN
Caminante, no hay camino
Se hace camino al andar.
("Walker, there is no path; the path is made by walking.") Antonio
Machado
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
RE: jdbc storage manager
Posted by "Lucente, Richard D" <ri...@lmco.com>.
My company recently went through this for sandesha2-1.2. Observations
were:
* The published documentation did not fully describe the semantics
needed. In particular, the inmemory solution appears to enforce
pessimistic row locking with serializable transaction isolation level.
Once beans are enlisted in a transaction, all other threads attempting
to access the bean block until the bean is released from its
transaction. It's not possible to implement a persistence solution
without combing through the inmemory and sandesha2 implementations and
capturing the same semantics.
* The InMemoryStorageManager persists Axis2 message contexts.
These hold transports (open socket connections) that cannot be stored in
a database.
* The sandesha beans use primitive types to hold values. Private
flags are used within the beans to denote which primitive fields are
important to the match function used by queries. Since these flags are
private, we had to come up with work arounds to use hibernate's "query
by example".
* The "time to send" comparison in the match function uses "<"
which doesn't work with hibernate's "query by example". We had to do
those checks separately.
Bottom line: it was more of a challenge than we initially thought. I
am, unfortunately, unable to share the result of our efforts. You may
want to take a look at project Mercury as an alternative.
-----Original Message-----
From: Thomas McKiernan [mailto:MCKIERNA@uk.ibm.com]
Sent: Monday, October 13, 2008 9:49 AM
To: sandesha-dev@ws.apache.org
Subject: jdbc storage manager
Hi guys,
I believe this question may have been asked before but I couldn't find
anything in the archives.
I was wondering if anybody had tried implementing a persistent (e.g.
JDBC)
version of the sandesha2 storage APIs?
If so can they share where they got with it, any issues they faced and
whether they committed it up to open source anywhere?
And has anyone got any other information related to this question?
Many thanks,
Thomas
----------------------------------
Thomas McKiernan
WebSphere Messaging Development,
IBM United Kingdom Limited
Internal Phone: 248241
External Phone: +44 (0)1962 818241
Mobile: +44 (0)789 1737497
Email: MCKIERNA@uk.ibm.com
Mail Point 211, IBM, Hursley Park, Winchester, Hampshire, England, SO21
2JN
Caminante, no hay camino
Se hace camino al andar.
("Walker, there is no path; the path is made by walking.") Antonio
Machado
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: jdbc storage manager
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Thomas,
I implemented a persistent implementation sometime back. The code (when
I last updated about an year ago) was in a working but experimental
stage. This may not work correctly with the current Sandesha2 head.
You can find it in the WSO2 repository given below. Code couldn't be
committed to Apache since it was based on Hibernate.
https://wso2.org/repos/wso2/trunk/commons/sandesha2-persistence/
Chamikara
Thomas McKiernan wrote:
> Hi guys,
>
> I believe this question may have been asked before but I couldn't find
> anything in the archives.
> I was wondering if anybody had tried implementing a persistent (e.g. JDBC)
> version of the sandesha2 storage APIs?
>
> If so can they share where they got with it, any issues they faced and
> whether they committed it up to open source anywhere?
> And has anyone got any other information related to this question?
>
> Many thanks,
> Thomas
> ----------------------------------
> Thomas McKiernan
>
> WebSphere Messaging Development,
> IBM United Kingdom Limited
>
> Internal Phone: 248241
> External Phone: +44 (0)1962 818241
> Mobile: +44 (0)789 1737497
> Email: MCKIERNA@uk.ibm.com
>
> Mail Point 211, IBM, Hursley Park, Winchester, Hampshire, England, SO21
> 2JN
>
>
> Caminante, no hay camino
> Se hace camino al andar.
> ("Walker, there is no path; the path is made by walking.") Antonio
> Machado
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org