Hi Thomas,
Looks good. +1 for the change.
Chamikara
On 3/20/07, Thomas McKiernan <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
