transaction id

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

transaction id

sunh11373
Hi,

Does anyone know why it is the client's responsibility to provide a transaction
id?


Thanks

(-------------------------------)               {((((((
(           Hang Sun            )              /_  _  )
(     [hidden email]       )             ( .  .   )
(  http://www.suns-online.com   )              ( /   )
(-------------------------------)-------oOOo------------oOOo---)
Reply | Threaded
Open this post in threaded view
|

Re: transaction id

chirino
I think that if one is not specified then a default one is assigned.
But when using the default, then you would not be able to interleave
multiple transactions overs 1 connection.

Regards,
Hiram

On 3/17/06, Hang Sun <[hidden email]> wrote:

> Hi,
>
> Does anyone know why it is the client's responsibility to provide a transaction
> id?
>
>
> Thanks
>
> (-------------------------------)               {((((((
> (           Hang Sun            )              /_  _  )
> (     [hidden email]       )             ( .  .   )
> (  http://www.suns-online.com   )              ( /   )
> (-------------------------------)-------oOOo------------oOOo---)
>


--
Regards,
Hiram
Reply | Threaded
Open this post in threaded view
|

Re: transaction id

sunh11373
Hi,

If the default is being generated by the server, then how is it being
communicated back to client? There is no response message for BEGIN.

If client is responsible for generating the transaction id, it is difficult for
server to guarantee the ids are unique crossing different clients. It is much
easier to let the server controls the id generation.

Does it make sense?

Thanks



--- Hiram Chirino <[hidden email]> wrote:

> I think that if one is not specified then a default one is assigned.
> But when using the default, then you would not be able to interleave
> multiple transactions overs 1 connection.
>
> Regards,
> Hiram
>
> On 3/17/06, Hang Sun <[hidden email]> wrote:
> > Hi,
> >
> > Does anyone know why it is the client's responsibility to provide a
> transaction
> > id?
> >
> >
> > Thanks
> >
> > (-------------------------------)               {((((((
> > (           Hang Sun            )              /_  _  )
> > (     [hidden email]       )             ( .  .   )
> > (  http://www.suns-online.com   )              ( /   )
> > (-------------------------------)-------oOOo------------oOOo---)
> >
>
>
> --
> Regards,
> Hiram
>

(-------------------------------)               {((((((
(           Hang Sun            )              /_  _  )
(     [hidden email]       )             ( .  .   )
(  http://www.suns-online.com   )              ( /   )
(-------------------------------)-------oOOo------------oOOo---)
Reply | Threaded
Open this post in threaded view
|

Re: transaction id

Brian McCallister-5
Hmm, thought I replied to this:

"The transaction header is required, and the transaction identifier  
will be used for SEND, COMMIT, ABORT, and ACK frames to bind them to  
the named transaction."

The client must specify a name. The name must be unique within the  
context of that client, not the server as a whole. Presumably a  
server will map the client id to the server id, but this is  
transparent to the client.

-Brian

On Mar 20, 2006, at 11:56 AM, Hang Sun wrote:

> Hi,
>
> If the default is being generated by the server, then how is it being
> communicated back to client? There is no response message for BEGIN.
>
> If client is responsible for generating the transaction id, it is  
> difficult for
> server to guarantee the ids are unique crossing different clients.  
> It is much
> easier to let the server controls the id generation.
>
> Does it make sense?
>
> Thanks
>
>
>
> --- Hiram Chirino <[hidden email]> wrote:
>
>> I think that if one is not specified then a default one is assigned.
>> But when using the default, then you would not be able to interleave
>> multiple transactions overs 1 connection.
>>
>> Regards,
>> Hiram
>>
>> On 3/17/06, Hang Sun <[hidden email]> wrote:
>>> Hi,
>>>
>>> Does anyone know why it is the client's responsibility to provide a
>> transaction
>>> id?
>>>
>>>
>>> Thanks
>>>
>>> (-------------------------------)               {((((((
>>> (           Hang Sun            )              /_  _  )
>>> (     [hidden email]       )             ( .  .   )
>>> (  http://www.suns-online.com   )              ( /   )
>>> (-------------------------------)-------oOOo------------oOOo---)
>>>
>>
>>
>> --
>> Regards,
>> Hiram
>>
>
> (-------------------------------)               {((((((
> (           Hang Sun            )              /_  _  )
> (     [hidden email]       )             ( .  .   )
> (  http://www.suns-online.com   )              ( /   )
> (-------------------------------)-------oOOo------------oOOo---)

Reply | Threaded
Open this post in threaded view
|

Re: transaction id

Brian McCallister-5
In reply to this post by sunh11373

On Mar 17, 2006, at 9:06 AM, Hang Sun wrote:

> Does anyone know why it is the client's responsibility to provide a  
> transaction
> id?

If the client didn't provide an ID the client would still need to  
provide a correlation id for the BEGIN command in order to map the  
server generated transaction id to the one the client wants. Instead  
of having the client track this mapping, stomp has the server track  
this mapping.

The transaction id needs to be unique only within the context of the  
client's connection, not all clients. It also does not need to be an  
XA id in the case of a server which is using XA transactions.

-Brian

Reply | Threaded
Open this post in threaded view
|

Re: transaction id

Brian McCallister-5

On Mar 20, 2006, at 12:08 PM, Brian McCallister wrote:

>  It also does not need to be an XA id in the case of a server which  
> is using XA transactions.

Not that a stomp server can expose full XA compatibility right now  
anyway as there is no mechanism for the server to initiate a  
transaction, nor is there a two-phase commit mechanism.

-Brian
Reply | Threaded
Open this post in threaded view
|

Re: transaction id

sunh11373
In reply to this post by Brian McCallister-5
Hi,

Thanks for the clarification.

I think I miss the assumption that stomp is connection based (TCP) so that the
server will be able to track client based on the socket. In other cases, maybe
session id can be used. BTW, what is the future plan on using the session-id?


Thanks


--- Brian McCallister <[hidden email]> wrote:

>
> On Mar 17, 2006, at 9:06 AM, Hang Sun wrote:
>
> > Does anyone know why it is the client's responsibility to provide a  
> > transaction
> > id?
>
> If the client didn't provide an ID the client would still need to  
> provide a correlation id for the BEGIN command in order to map the  
> server generated transaction id to the one the client wants. Instead  
> of having the client track this mapping, stomp has the server track  
> this mapping.
>
> The transaction id needs to be unique only within the context of the  
> client's connection, not all clients. It also does not need to be an  
> XA id in the case of a server which is using XA transactions.
>
> -Brian
>
>

Reply | Threaded
Open this post in threaded view
|

Re: transaction id

Brian McCallister-5
Right now the session-id on the CONNECTED frame provides a unique  
identifier for the client in case it needs one. The most common case  
is creating a temporary queue for replies and whatnot. Different  
servers support, or don't support, temporary destinations, and this  
allows for the creation thereof in a unique way under the control of  
the client.

In a future version of the spec I expect it will also be used for  
durable subscriptions.

-Brian

On Mar 20, 2006, at 1:27 PM, Hang Sun wrote:

> Hi,
>
> Thanks for the clarification.
>
> I think I miss the assumption that stomp is connection based (TCP)  
> so that the
> server will be able to track client based on the socket. In other  
> cases, maybe
> session id can be used. BTW, what is the future plan on using the  
> session-id?
>
>
> Thanks
>
>
> --- Brian McCallister <[hidden email]> wrote:
>
>>
>> On Mar 17, 2006, at 9:06 AM, Hang Sun wrote:
>>
>>> Does anyone know why it is the client's responsibility to provide a
>>> transaction
>>> id?
>>
>> If the client didn't provide an ID the client would still need to
>> provide a correlation id for the BEGIN command in order to map the
>> server generated transaction id to the one the client wants. Instead
>> of having the client track this mapping, stomp has the server track
>> this mapping.
>>
>> The transaction id needs to be unique only within the context of the
>> client's connection, not all clients. It also does not need to be an
>> XA id in the case of a server which is using XA transactions.
>>
>> -Brian
>>
>>
>