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 2007/03/20 13:56:37 UTC
storage manager generalization
Hi everyone,
At the moment Sandesha supports two storage managers - a persistent store
and an immemory store. We would like to generalize this so that sandesha
can support any number of storage managers.
In more detail, we would like to make the following changes:
1. Change the module.xml to allow for multiple storage managers. Each
storage manager entry defines a name and a classname. Additionally one
storage manager can be defined as default. Also, the current RM global
properties (InOrder etc) are moved inside each storage manager e.g. strg
mgr 1 has InOrder persistent, strg mgr 2 is not InOrder and inmemory.
2. At module load time the module is parsed into a storage manager map.
This map can also be manipulated programmatically - adding new stores
etc.Stores are then looked up by their name. Load time is also when we
police the module xml - ensuring no duplicate names and not more than one
default mgr.
3. The runtime behaviour of the code is changed as it now needs to lookup
the correct store.
Requestor: on application request, we require the operation ctx to have
been decorated with the correct strg mgr name to use. This can be done by
the SandeshaClient (or the default strg mgr is used).
For inbound messages we have to iterate the list to find the owning
storageManager for a sequence - the new storageManagerMap interface
exposes a method for us to do this (as well as add new strg mgrs, get by
name etc). This can be done in the global in handler and the msg ctx then
decorated with the correct strg mgr to use. The only exception to this is
processing the CreateSequence and CSResponse, as we have no useful
sequence info at this point. When the server receives the CS we need to
perform the strg mgr name lookup based on the name. This could be
decorated on the service (possibly the port, depending on what is
"resolvable" by the time we reach the global in handler). We can do this
using the services.xml file. If there is no decoration and no default
manager then we want to throw a fault. For the requestor side receiving
the CSResponse, we have to pre-decorate the op ctx with the correct
storage manager we used when sending the CreateSequence, and we can then
look this up.
If there are no objections to this change then I will raise a JIRA to
accommodate it.
Many thanks,
Thomas McKiernan
----------------------------------
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: storage manager generalization
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Thomas,
Looks good. +1 for the change.
Chamikara
On 3/20/07, Thomas McKiernan <MC...@uk.ibm.com> wrote:
>
> Hi everyone,
>
> At the moment Sandesha supports two storage managers - a persistent store
> and an immemory store. We would like to generalize this so that sandesha
> can support any number of storage managers.
>
> In more detail, we would like to make the following changes:
>
> 1. Change the module.xml to allow for multiple storage managers. Each
> storage manager entry defines a name and a classname. Additionally one
> storage manager can be defined as default. Also, the current RM global
> properties (InOrder etc) are moved inside each storage manager e.g. strg
> mgr 1 has InOrder persistent, strg mgr 2 is not InOrder and inmemory.
>
> 2. At module load time the module is parsed into a storage manager map.
> This map can also be manipulated programmatically - adding new stores
> etc.Stores are then looked up by their name. Load time is also when we
> police the module xml - ensuring no duplicate names and not more than one
> default mgr.
>
> 3. The runtime behaviour of the code is changed as it now needs to lookup
> the correct store.
> Requestor: on application request, we require the operation ctx to have
> been decorated with the correct strg mgr name to use. This can be done by
> the SandeshaClient (or the default strg mgr is used).
>
> For inbound messages we have to iterate the list to find the owning
> storageManager for a sequence - the new storageManagerMap interface
> exposes a method for us to do this (as well as add new strg mgrs, get by
> name etc). This can be done in the global in handler and the msg ctx then
> decorated with the correct strg mgr to use. The only exception to this is
> processing the CreateSequence and CSResponse, as we have no useful
> sequence info at this point. When the server receives the CS we need to
> perform the strg mgr name lookup based on the name. This could be
> decorated on the service (possibly the port, depending on what is
> "resolvable" by the time we reach the global in handler). We can do this
> using the services.xml file. If there is no decoration and no default
> manager then we want to throw a fault. For the requestor side receiving
> the CSResponse, we have to pre-decorate the op ctx with the correct
> storage manager we used when sending the CreateSequence, and we can then
> look this up.
>
> If there are no objections to this change then I will raise a JIRA to
> accommodate it.
>
> Many thanks,
> Thomas McKiernan
>
> ----------------------------------
> 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: storage manager generalization
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Thomas,
Looks good. +1 for the change.
Chamikara
On 3/20/07, Thomas McKiernan <MC...@uk.ibm.com> wrote:
>
> Hi everyone,
>
> At the moment Sandesha supports two storage managers - a persistent store
> and an immemory store. We would like to generalize this so that sandesha
> can support any number of storage managers.
>
> In more detail, we would like to make the following changes:
>
> 1. Change the module.xml to allow for multiple storage managers. Each
> storage manager entry defines a name and a classname. Additionally one
> storage manager can be defined as default. Also, the current RM global
> properties (InOrder etc) are moved inside each storage manager e.g. strg
> mgr 1 has InOrder persistent, strg mgr 2 is not InOrder and inmemory.
>
> 2. At module load time the module is parsed into a storage manager map.
> This map can also be manipulated programmatically - adding new stores
> etc.Stores are then looked up by their name. Load time is also when we
> police the module xml - ensuring no duplicate names and not more than one
> default mgr.
>
> 3. The runtime behaviour of the code is changed as it now needs to lookup
> the correct store.
> Requestor: on application request, we require the operation ctx to have
> been decorated with the correct strg mgr name to use. This can be done by
> the SandeshaClient (or the default strg mgr is used).
>
> For inbound messages we have to iterate the list to find the owning
> storageManager for a sequence - the new storageManagerMap interface
> exposes a method for us to do this (as well as add new strg mgrs, get by
> name etc). This can be done in the global in handler and the msg ctx then
> decorated with the correct strg mgr to use. The only exception to this is
> processing the CreateSequence and CSResponse, as we have no useful
> sequence info at this point. When the server receives the CS we need to
> perform the strg mgr name lookup based on the name. This could be
> decorated on the service (possibly the port, depending on what is
> "resolvable" by the time we reach the global in handler). We can do this
> using the services.xml file. If there is no decoration and no default
> manager then we want to throw a fault. For the requestor side receiving
> the CSResponse, we have to pre-decorate the op ctx with the correct
> storage manager we used when sending the CreateSequence, and we can then
> look this up.
>
> If there are no objections to this change then I will raise a JIRA to
> accommodate it.
>
> Many thanks,
> Thomas McKiernan
>
> ----------------------------------
> 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
>
>