Same JMS/JDBC resource optimizes to normal database commit

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Same JMS/JDBC resource optimizes to normal database commit

richard emberson-2
My question concerns whether or not the Bitronix Transaction
Manager will optimize a 2PC to a normal database commit
if the JMS and JDBC resources are, under the covers, using
the same database.

Specifically, I've got an input JMS queue from which
a message is read. A JDBC set of tables where message
specific application data is read and written.
And, an output JMS queue to which a message is sent.
Also, each message via an identifier has its own
application data in rows in the database table(s); there is
never a case where the JDBC statements of two messages will
read or write to the same row.
I do not know what the table/row structure of the JMS tables
in the database; whether the read/write of two different messages
will require accessing the same row of a given table or not.

I need to read a message from an input JMS queue. Read application
data associated with that message. Generated additional application
data. And then, transactionally,
     1) remove the input messsage from the input queue,
     2) write the additional application data to the database, and
     3) put a new message in an output JMS queue.
Will the Bitronix Transaction Manager optimize
and do a regular old database commit rather than an XA commit?
If not, would it be a simple matter to make Bitronix do such
an optimization?

Thanks
Richard

--
Quis custodiet ipsos custodes


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Same JMS/JDBC resource optimizes to normal database commit

Ludovic Orban-2
It might be possible to do that today, but that depends on your JMS
server's flexibility. The fact that the transaction can be simplified
to a 1PC one also depends on your database but with some BTM config
tweaks, there's a good chance this will work just fine.

The idea is very simple: configure a BTM datasource make sure both
your application and JMS server use the exact same one. If your
database is smart enough, it will figure out the two sub-transactions
are related and will instruct the transaction manager to 'merge' (or
'join' in XA parlance) them which will enable BTM to apply the
one-phase commit optimization. If your DB isn't smart enough, you may
want to try enabling shareTransactionConnections on your datasource
which will roughly end up doing the same thing, with the limitation
that all DB accesses and JMS accesses must happen in the same thread
otherwise BTM will have to fallback to plain old two-phase commit.

I hope this answers your question.

On Tue, Jun 26, 2012 at 3:49 AM, richard emberson
<[hidden email]> wrote:

> My question concerns whether or not the Bitronix Transaction
> Manager will optimize a 2PC to a normal database commit
> if the JMS and JDBC resources are, under the covers, using
> the same database.
>
> Specifically, I've got an input JMS queue from which
> a message is read. A JDBC set of tables where message
> specific application data is read and written.
> And, an output JMS queue to which a message is sent.
> Also, each message via an identifier has its own
> application data in rows in the database table(s); there is
> never a case where the JDBC statements of two messages will
> read or write to the same row.
> I do not know what the table/row structure of the JMS tables
> in the database; whether the read/write of two different messages
> will require accessing the same row of a given table or not.
>
> I need to read a message from an input JMS queue. Read application
> data associated with that message. Generated additional application
> data. And then, transactionally,
>    1) remove the input messsage from the input queue,
>    2) write the additional application data to the database, and
>    3) put a new message in an output JMS queue.
> Will the Bitronix Transaction Manager optimize
> and do a regular old database commit rather than an XA commit?
> If not, would it be a simple matter to make Bitronix do such
> an optimization?
>
> Thanks
> Richard
>
> --
> Quis custodiet ipsos custodes
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Same JMS/JDBC resource optimizes to normal database commit

richard emberson-2
Since I have a special configuration, a single database doing
both JMS and application data storage, and I do not plan to
have two different databases, is there a particular place
in the BTM code where I could simply tell BTM to 'merge'
the sub-transaction. Even if it means going in and changing the
BTM code, that would work for me. Relying of the database's
connector to figure things out might work, but, as you suggest,
not all databases have such a capability. It would be
simplier to just "adjust" the BTM code for my special case
(yea, its not standard, but with this backdoor there would
be much better performance). For example, if BTM had a flag,
say, btm.is.single.datasource=true, which would force BTM
to simply assume that it should merge all sub-transactions
associated with the commits of a given thread.

It might be a non-standard hack, but a very useful one.

Also, the application is multi-threaded. There are multiple
thread, but each thread is doing its own, independent task
which was described in my first email (read from JMS, process
message, write to JMS and database).
 From what you said about using shareTransactionConnections
seems to imply that with multiple threads this approach
will not work. Is that right?


On 06/26/2012 01:55 AM, Ludovic Orban wrote:

> It might be possible to do that today, but that depends on your JMS
> server's flexibility. The fact that the transaction can be simplified
> to a 1PC one also depends on your database but with some BTM config
> tweaks, there's a good chance this will work just fine.
>
> The idea is very simple: configure a BTM datasource make sure both
> your application and JMS server use the exact same one. If your
> database is smart enough, it will figure out the two sub-transactions
> are related and will instruct the transaction manager to 'merge' (or
> 'join' in XA parlance) them which will enable BTM to apply the
> one-phase commit optimization. If your DB isn't smart enough, you may
> want to try enabling shareTransactionConnections on your datasource
> which will roughly end up doing the same thing, with the limitation
> that all DB accesses and JMS accesses must happen in the same thread
> otherwise BTM will have to fallback to plain old two-phase commit.
>
> I hope this answers your question.
>
> On Tue, Jun 26, 2012 at 3:49 AM, richard emberson
> <[hidden email]> wrote:
>> My question concerns whether or not the Bitronix Transaction
>> Manager will optimize a 2PC to a normal database commit
>> if the JMS and JDBC resources are, under the covers, using
>> the same database.
>>
>> Specifically, I've got an input JMS queue from which
>> a message is read. A JDBC set of tables where message
>> specific application data is read and written.
>> And, an output JMS queue to which a message is sent.
>> Also, each message via an identifier has its own
>> application data in rows in the database table(s); there is
>> never a case where the JDBC statements of two messages will
>> read or write to the same row.
>> I do not know what the table/row structure of the JMS tables
>> in the database; whether the read/write of two different messages
>> will require accessing the same row of a given table or not.
>>
>> I need to read a message from an input JMS queue. Read application
>> data associated with that message. Generated additional application
>> data. And then, transactionally,
>>     1) remove the input messsage from the input queue,
>>     2) write the additional application data to the database, and
>>     3) put a new message in an output JMS queue.
>> Will the Bitronix Transaction Manager optimize
>> and do a regular old database commit rather than an XA commit?
>> If not, would it be a simple matter to make Bitronix do such
>> an optimization?
>>
>> Thanks
>> Richard
>>
>> --
>> Quis custodiet ipsos custodes
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>      http://xircles.codehaus.org/manage_email
>
>

--
Quis custodiet ipsos custodes



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Same JMS/JDBC resource optimizes to normal database commit

Ludovic Orban-2
What you're asking simply isn't possible: BTM cannot merge two
sub-transactions (called 'branches' in XA parlance) without guidance
and support from the resource (the DB in your case). Asking a JDBC
driver to merge two unrelated branches will simply result in an
exception.

There are good reasons why the mechanism works this way and all the
possible optimizations are taken into account by the XA spec so if a
DB does not support them that usually is because of a good reason and
there's nothing BTM can do about that.

The shareTransactionConnections is the only possible trick to get a
relatively close result. The idea is that the connection pool pins
requested JDBC connections to the calling thread and each time a new
connection is requested by the same thread, the exact same connection
is returned. This actually is a trick at the connection pool level,
not at the transaction manager one. As long as you can guarantee that
all your DB work will happen in the same thread, it will end up on the
same connection and transitively in the same transaction. If for some
reason your JMS server isn't co-located in the same process and/or
does its DB work in another thread then there's nothing that can be
done at any level and by any XA transaction manager out there.


On Tue, Jun 26, 2012 at 4:27 PM, richard emberson
<[hidden email]> wrote:

> Since I have a special configuration, a single database doing
> both JMS and application data storage, and I do not plan to
> have two different databases, is there a particular place
> in the BTM code where I could simply tell BTM to 'merge'
> the sub-transaction. Even if it means going in and changing the
> BTM code, that would work for me. Relying of the database's
> connector to figure things out might work, but, as you suggest,
> not all databases have such a capability. It would be
> simplier to just "adjust" the BTM code for my special case
> (yea, its not standard, but with this backdoor there would
> be much better performance). For example, if BTM had a flag,
> say, btm.is.single.datasource=true, which would force BTM
> to simply assume that it should merge all sub-transactions
> associated with the commits of a given thread.
>
> It might be a non-standard hack, but a very useful one.
>
> Also, the application is multi-threaded. There are multiple
> thread, but each thread is doing its own, independent task
> which was described in my first email (read from JMS, process
> message, write to JMS and database).
> From what you said about using shareTransactionConnections
> seems to imply that with multiple threads this approach
> will not work. Is that right?
>
>
> On 06/26/2012 01:55 AM, Ludovic Orban wrote:
>>
>> It might be possible to do that today, but that depends on your JMS
>> server's flexibility. The fact that the transaction can be simplified
>> to a 1PC one also depends on your database but with some BTM config
>> tweaks, there's a good chance this will work just fine.
>>
>> The idea is very simple: configure a BTM datasource make sure both
>> your application and JMS server use the exact same one. If your
>> database is smart enough, it will figure out the two sub-transactions
>> are related and will instruct the transaction manager to 'merge' (or
>> 'join' in XA parlance) them which will enable BTM to apply the
>> one-phase commit optimization. If your DB isn't smart enough, you may
>> want to try enabling shareTransactionConnections on your datasource
>> which will roughly end up doing the same thing, with the limitation
>> that all DB accesses and JMS accesses must happen in the same thread
>> otherwise BTM will have to fallback to plain old two-phase commit.
>>
>> I hope this answers your question.
>>
>> On Tue, Jun 26, 2012 at 3:49 AM, richard emberson
>> <[hidden email]> wrote:
>>>
>>> My question concerns whether or not the Bitronix Transaction
>>> Manager will optimize a 2PC to a normal database commit
>>> if the JMS and JDBC resources are, under the covers, using
>>> the same database.
>>>
>>> Specifically, I've got an input JMS queue from which
>>> a message is read. A JDBC set of tables where message
>>> specific application data is read and written.
>>> And, an output JMS queue to which a message is sent.
>>> Also, each message via an identifier has its own
>>> application data in rows in the database table(s); there is
>>> never a case where the JDBC statements of two messages will
>>> read or write to the same row.
>>> I do not know what the table/row structure of the JMS tables
>>> in the database; whether the read/write of two different messages
>>> will require accessing the same row of a given table or not.
>>>
>>> I need to read a message from an input JMS queue. Read application
>>> data associated with that message. Generated additional application
>>> data. And then, transactionally,
>>>    1) remove the input messsage from the input queue,
>>>    2) write the additional application data to the database, and
>>>    3) put a new message in an output JMS queue.
>>> Will the Bitronix Transaction Manager optimize
>>> and do a regular old database commit rather than an XA commit?
>>> If not, would it be a simple matter to make Bitronix do such
>>> an optimization?
>>>
>>> Thanks
>>> Richard
>>>
>>> --
>>> Quis custodiet ipsos custodes
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>   http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>
> --
> Quis custodiet ipsos custodes
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Same JMS/JDBC resource optimizes to normal database commit

richard emberson-2

Thank you for you patience.

It just seems like such a common use-case with significant
performance effects, that there would be blogs written
about how to do it or, at least, which combination of
transaction manager, JDBC and JMS libraries and which
database allow one to do it. And, each container
framework and/or transaction manager would detail how
to support such a (non-standard) optimization.

That said, you would not happen to know if there is
an existing combination or combinations of
database/JMS/JDBC which will yield the optimization when
used with BTM?

Thanks again. I will report back any successes.

Richard

On 06/26/2012 08:25 AM, Ludovic Orban wrote:

> What you're asking simply isn't possible: BTM cannot merge two
> sub-transactions (called 'branches' in XA parlance) without guidance
> and support from the resource (the DB in your case). Asking a JDBC
> driver to merge two unrelated branches will simply result in an
> exception.
>
> There are good reasons why the mechanism works this way and all the
> possible optimizations are taken into account by the XA spec so if a
> DB does not support them that usually is because of a good reason and
> there's nothing BTM can do about that.
>
> The shareTransactionConnections is the only possible trick to get a
> relatively close result. The idea is that the connection pool pins
> requested JDBC connections to the calling thread and each time a new
> connection is requested by the same thread, the exact same connection
> is returned. This actually is a trick at the connection pool level,
> not at the transaction manager one. As long as you can guarantee that
> all your DB work will happen in the same thread, it will end up on the
> same connection and transitively in the same transaction. If for some
> reason your JMS server isn't co-located in the same process and/or
> does its DB work in another thread then there's nothing that can be
> done at any level and by any XA transaction manager out there.
>
>
> On Tue, Jun 26, 2012 at 4:27 PM, richard emberson
> <[hidden email]> wrote:
>> Since I have a special configuration, a single database doing
>> both JMS and application data storage, and I do not plan to
>> have two different databases, is there a particular place
>> in the BTM code where I could simply tell BTM to 'merge'
>> the sub-transaction. Even if it means going in and changing the
>> BTM code, that would work for me. Relying of the database's
>> connector to figure things out might work, but, as you suggest,
>> not all databases have such a capability. It would be
>> simplier to just "adjust" the BTM code for my special case
>> (yea, its not standard, but with this backdoor there would
>> be much better performance). For example, if BTM had a flag,
>> say, btm.is.single.datasource=true, which would force BTM
>> to simply assume that it should merge all sub-transactions
>> associated with the commits of a given thread.
>>
>> It might be a non-standard hack, but a very useful one.
>>
>> Also, the application is multi-threaded. There are multiple
>> thread, but each thread is doing its own, independent task
>> which was described in my first email (read from JMS, process
>> message, write to JMS and database).
>>  From what you said about using shareTransactionConnections
>> seems to imply that with multiple threads this approach
>> will not work. Is that right?
>>
>>
>> On 06/26/2012 01:55 AM, Ludovic Orban wrote:
>>>
>>> It might be possible to do that today, but that depends on your JMS
>>> server's flexibility. The fact that the transaction can be simplified
>>> to a 1PC one also depends on your database but with some BTM config
>>> tweaks, there's a good chance this will work just fine.
>>>
>>> The idea is very simple: configure a BTM datasource make sure both
>>> your application and JMS server use the exact same one. If your
>>> database is smart enough, it will figure out the two sub-transactions
>>> are related and will instruct the transaction manager to 'merge' (or
>>> 'join' in XA parlance) them which will enable BTM to apply the
>>> one-phase commit optimization. If your DB isn't smart enough, you may
>>> want to try enabling shareTransactionConnections on your datasource
>>> which will roughly end up doing the same thing, with the limitation
>>> that all DB accesses and JMS accesses must happen in the same thread
>>> otherwise BTM will have to fallback to plain old two-phase commit.
>>>
>>> I hope this answers your question.
>>>
>>> On Tue, Jun 26, 2012 at 3:49 AM, richard emberson
>>> <[hidden email]> wrote:
>>>>
>>>> My question concerns whether or not the Bitronix Transaction
>>>> Manager will optimize a 2PC to a normal database commit
>>>> if the JMS and JDBC resources are, under the covers, using
>>>> the same database.
>>>>
>>>> Specifically, I've got an input JMS queue from which
>>>> a message is read. A JDBC set of tables where message
>>>> specific application data is read and written.
>>>> And, an output JMS queue to which a message is sent.
>>>> Also, each message via an identifier has its own
>>>> application data in rows in the database table(s); there is
>>>> never a case where the JDBC statements of two messages will
>>>> read or write to the same row.
>>>> I do not know what the table/row structure of the JMS tables
>>>> in the database; whether the read/write of two different messages
>>>> will require accessing the same row of a given table or not.
>>>>
>>>> I need to read a message from an input JMS queue. Read application
>>>> data associated with that message. Generated additional application
>>>> data. And then, transactionally,
>>>>     1) remove the input messsage from the input queue,
>>>>     2) write the additional application data to the database, and
>>>>     3) put a new message in an output JMS queue.
>>>> Will the Bitronix Transaction Manager optimize
>>>> and do a regular old database commit rather than an XA commit?
>>>> If not, would it be a simple matter to make Bitronix do such
>>>> an optimization?
>>>>
>>>> Thanks
>>>> Richard
>>>>
>>>> --
>>>> Quis custodiet ipsos custodes
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>    http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>      http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>> --
>> Quis custodiet ipsos custodes
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>      http://xircles.codehaus.org/manage_email
>
>

--
Quis custodiet ipsos custodes



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Same JMS/JDBC resource optimizes to normal database commit

Ludovic Orban-2
Sorry, I'm not that much in JMS and I'm not aware of any such server.
You may want to query the different JMS servers' mailing lists, you
might get lucky.

If not, that could be a nice project to work on: a simple embedded JMS
server with a JDBC backend though I would need sponsoring to work on
it. Or maybe you could build it yourself.


On Tue, Jun 26, 2012 at 7:35 PM, richard emberson
<[hidden email]> wrote:

>
> Thank you for you patience.
>
> It just seems like such a common use-case with significant
> performance effects, that there would be blogs written
> about how to do it or, at least, which combination of
> transaction manager, JDBC and JMS libraries and which
> database allow one to do it. And, each container
> framework and/or transaction manager would detail how
> to support such a (non-standard) optimization.
>
> That said, you would not happen to know if there is
> an existing combination or combinations of
> database/JMS/JDBC which will yield the optimization when
> used with BTM?
>
> Thanks again. I will report back any successes.
>
> Richard
>
>
> On 06/26/2012 08:25 AM, Ludovic Orban wrote:
>>
>> What you're asking simply isn't possible: BTM cannot merge two
>> sub-transactions (called 'branches' in XA parlance) without guidance
>> and support from the resource (the DB in your case). Asking a JDBC
>> driver to merge two unrelated branches will simply result in an
>> exception.
>>
>> There are good reasons why the mechanism works this way and all the
>> possible optimizations are taken into account by the XA spec so if a
>> DB does not support them that usually is because of a good reason and
>> there's nothing BTM can do about that.
>>
>> The shareTransactionConnections is the only possible trick to get a
>> relatively close result. The idea is that the connection pool pins
>> requested JDBC connections to the calling thread and each time a new
>> connection is requested by the same thread, the exact same connection
>> is returned. This actually is a trick at the connection pool level,
>> not at the transaction manager one. As long as you can guarantee that
>> all your DB work will happen in the same thread, it will end up on the
>> same connection and transitively in the same transaction. If for some
>> reason your JMS server isn't co-located in the same process and/or
>> does its DB work in another thread then there's nothing that can be
>> done at any level and by any XA transaction manager out there.
>>
>>
>> On Tue, Jun 26, 2012 at 4:27 PM, richard emberson
>> <[hidden email]> wrote:
>>>
>>> Since I have a special configuration, a single database doing
>>> both JMS and application data storage, and I do not plan to
>>> have two different databases, is there a particular place
>>> in the BTM code where I could simply tell BTM to 'merge'
>>> the sub-transaction. Even if it means going in and changing the
>>> BTM code, that would work for me. Relying of the database's
>>> connector to figure things out might work, but, as you suggest,
>>> not all databases have such a capability. It would be
>>> simplier to just "adjust" the BTM code for my special case
>>> (yea, its not standard, but with this backdoor there would
>>> be much better performance). For example, if BTM had a flag,
>>> say, btm.is.single.datasource=true, which would force BTM
>>> to simply assume that it should merge all sub-transactions
>>> associated with the commits of a given thread.
>>>
>>> It might be a non-standard hack, but a very useful one.
>>>
>>> Also, the application is multi-threaded. There are multiple
>>> thread, but each thread is doing its own, independent task
>>> which was described in my first email (read from JMS, process
>>> message, write to JMS and database).
>>>  From what you said about using shareTransactionConnections
>>> seems to imply that with multiple threads this approach
>>> will not work. Is that right?
>>>
>>>
>>> On 06/26/2012 01:55 AM, Ludovic Orban wrote:
>>>>
>>>>
>>>> It might be possible to do that today, but that depends on your JMS
>>>> server's flexibility. The fact that the transaction can be simplified
>>>> to a 1PC one also depends on your database but with some BTM config
>>>> tweaks, there's a good chance this will work just fine.
>>>>
>>>> The idea is very simple: configure a BTM datasource make sure both
>>>> your application and JMS server use the exact same one. If your
>>>> database is smart enough, it will figure out the two sub-transactions
>>>> are related and will instruct the transaction manager to 'merge' (or
>>>> 'join' in XA parlance) them which will enable BTM to apply the
>>>> one-phase commit optimization. If your DB isn't smart enough, you may
>>>> want to try enabling shareTransactionConnections on your datasource
>>>> which will roughly end up doing the same thing, with the limitation
>>>> that all DB accesses and JMS accesses must happen in the same thread
>>>> otherwise BTM will have to fallback to plain old two-phase commit.
>>>>
>>>> I hope this answers your question.
>>>>
>>>> On Tue, Jun 26, 2012 at 3:49 AM, richard emberson
>>>> <[hidden email]> wrote:
>>>>>
>>>>>
>>>>> My question concerns whether or not the Bitronix Transaction
>>>>> Manager will optimize a 2PC to a normal database commit
>>>>> if the JMS and JDBC resources are, under the covers, using
>>>>> the same database.
>>>>>
>>>>> Specifically, I've got an input JMS queue from which
>>>>> a message is read. A JDBC set of tables where message
>>>>> specific application data is read and written.
>>>>> And, an output JMS queue to which a message is sent.
>>>>> Also, each message via an identifier has its own
>>>>> application data in rows in the database table(s); there is
>>>>> never a case where the JDBC statements of two messages will
>>>>> read or write to the same row.
>>>>> I do not know what the table/row structure of the JMS tables
>>>>> in the database; whether the read/write of two different messages
>>>>> will require accessing the same row of a given table or not.
>>>>>
>>>>> I need to read a message from an input JMS queue. Read application
>>>>> data associated with that message. Generated additional application
>>>>> data. And then, transactionally,
>>>>>    1) remove the input messsage from the input queue,
>>>>>    2) write the additional application data to the database, and
>>>>>    3) put a new message in an output JMS queue.
>>>>> Will the Bitronix Transaction Manager optimize
>>>>> and do a regular old database commit rather than an XA commit?
>>>>> If not, would it be a simple matter to make Bitronix do such
>>>>> an optimization?
>>>>>
>>>>> Thanks
>>>>> Richard
>>>>>
>>>>> --
>>>>> Quis custodiet ipsos custodes
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list, please visit:
>>>>>
>>>>>   http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>     http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>
>>> --
>>> Quis custodiet ipsos custodes
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>   http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>
> --
> Quis custodiet ipsos custodes
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email