On Wed, 2006-12-06 at 15:42 +0100, Guillaume Nodet wrote: On 12/6/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I'm interested in defining the transaction behaviour of components inside a JBI > > ESB. Of course for the components to be portable among different JBI container > > the beahviuor of the component and of the container should be standardized. I > > feel the JBI specification is not enough on this issue. > > Yeah, I agree. > > > Basing on my experience > > with traditional integration brokers I also feel that the implementation > > choices that servicemix is undergoing could not meet some common transactional > > scenarios. > > What kind of scenarios can not be handled ? > While the transaction model in servicemix is not controlled by the MEP > of the exchange, > but by the synchronous / asynchronous sending of the exchange, it can handle > all the possible use cases afaik (though it only handle XA transactions). > For example a scenario in which the transaction semantic must be variable so that a node (service unit/endpoint) has a transaction behaviour, the following one have another behaviour. This may be needed by the flow (with flow here and usually I mean a group of service unit that together creates an integration dataflow) functional semantic or also because the resources on which the service unit is based aren't transaction capable (for example the HTTP protocol). For what I understand servicemix at the moment the transaction configuration in ESB instance wide. It is not really clear to me how given a component Servicemix chooses wich flow (here with flow I mean the flow types handled by sm like seda or jca) to use, but I understand that all service unit connected together must have the same servicemix-flow. This implies that all the service units will have the same transaction semantic (provided they are transaction capable, I don't know what happens otherwise) and as I said this not always the wanted behaviour.
> > Therefore I'd like to propose you the following transaction model. It's just a > > skecth but please evaluate it and let's discuss it. > > > > ------------------ > > A transaction model for jbi esb > > A transaction model for a jbi esb should define how transaction are handled in a > > consistent and forecastable way. > > A transaction model should allow to mix transactional and non transactional > > components (BC and SE) and should allow to mix them so allowing to create non > > transactional flows (no component in the flow is transactional or use > > transaction), partially transactional flow (some component in the flow is > > transactional and use transaction) and fully transactional flow (every > > component in the flow is transactional and use transaction). > > Agreed. > > > An esb jbi should allow these kind flows to cohexists in the same instance. > > In my opinion the transaction behaviuor should be configurable with the > > granularity of the service unit, that is each service unit must be able to > > specify its transactional behaviour. > > Or on an endpoint level. Of course both would match if the SU contains > a single endpoint. The declaration of these metadata on the SU would allow > the use of the SU jbi descriptor. But I doubt it can be completely handled > by the container itself, and I guess the components will need to change > its behavior depending on these metadata. So it would not be portable across > containers and components, unless they all agree on the same spec. > I agree that the endpoit granularity is better and agree with other considerations. > > Before delving into this transactional behaviuor proposal it may be useful to > > focus on wich are the transactional resources and the transactional operations > > inside an ESB. > > A delivery channel should be considered a transactional resource so the act of > > consuming and of sending a message should be considered transactional > > operations. > > Any other traditional transactional resource (like database) used inside a > > component could potentially participate to the transaction assocated with the > > service unit execution and so must be taken into account in this discussion. > > For binding components the act of communicating with an external peer should be > > considered a transactional operation if the external process and the > > communication protocol support the concept of transaction. > > Agreed > > > > > I propose three level of transaction support for a component: > > 1. none > > 2. transacted > > 3. XA transacted > > > > 1. in the none transaction behaviour every transactional operation is committed > > the moment it is executed (autocommit). This is mandatory for the operation > > done on the delivery channel and for the operations done on external peers. > > The transactional resources handled by the component may be freely used. So the > > component may allocate a transaction and commit it when it wants. > > > > 2. in the transacted mode the act of consuming a message from delivery channel > > or from an external peer is transactional. The transaction is open at the > > beginning of the exchange processing and is committed at the end if and only if > > the processing does'not end with an error or an unandled exception. A fault is > > instead considered a normal resutl and thus the transaction is commited. > > The act of sending message on the delivery channel or to an external peer occurs > > in autocommit mode and the component is free to handle its internal resource as > > in the none transaction mode. > > When sending a message if the message exchange pattern is synchronous and the > > resource orginating the message is the delivery channel the allocated > > transaction is propagated to the endpoint cosuming the message so that the > > consumption occurs in the same transaction. This happens iteratively so that a > > fully synchronous flow uses one transaction. > > When the message pattern is asynchronous a new trasaction must be allocated for > > every act of consuming the message. There sould also be a way to tell the > > container if these asynchronous messages must be persisted or not. This should > > be configurable at the sending service unit level. > > You are talking about jms transactions, jdbc transactions without xa, right ? > If you start a jms transaction when consuming a jms message and send it'm not sure > asynchronously in the NMR, you want both to be transacted, else you will have > a point of failure: the only way to do that is to use XA. So I think > this use case > only works when the message is send synchronously in the NMR. > It make sense with InOnly MEP to send a message (a persistent one) and don't wait for the answer. The act of sending in this case wouldn't be bound to the transaction open when consuming the message. Inside a service unit I may need to send message to different destinations and not in every case I need to be under a single XA transaction. I dThe case you're describing refers to the XA scenario where the MEP is synchronous. In this case the whole flow is under a sin't agree when you say that there is a point of failure. As in every scenario somethig may go wrong, in this case the component (not the transaction manager) will have to handle it. anyway in many cases when a binding component uses a non transactional protocol this is what you'll have to do anyway. > For the persistence point, this can already be controlled, but I agree we need > to be able to define it on the SU / endpoint level. > again I think it is not a servicemix problem but a specification lack. Anyway servimix can try to promote a new standard revision. > > > > 3. in the XA transacted mode the act of consuming messages from delivery channel > > and from an external peer is transactional and the allocated transaction is an > > XA transaction. This is of course possible only if the transactional resources > > are XA capable. The XA transaction is commited at the end of the message > > exchenge execution with the same rules of the transacted behaviour. > > The delivery channel in a JBI BUS should be XA capable since it is implemented > > by a messaging middleware. Any internal reosurce used by the component must be > > XA and must be enlisted in the transaction. > > When sending a message if the MEP is asyncrhonous the operation must be enlisted > > in the XA transaction. > > if the MEP is synchronous the act of sending must be in autocommit mode but the > > the transaction must be propagated to the consuming endpoint. > > > > please notice that the transaction semantic is implied by the MEP and not by the > > API used to send the message on the delivery channel. > > This is the main point I don't understand. > > Let's take the use case of a service engine that needs to send an InOnly mep > to a given service and an InOut mep to another one. If you want the whole > thing to be transactional, you need to call a sendSync on the InOnly > (and have the transaction conveyed) so that you can receive the ERROR > status (if any) and rollback the transaction if needed. > My point of view is different: the transaction semantic of sending a message with the InOnly MEP is that the delivery channel ha successfully received the message. If you want to be sure that the message has been correctly processed by the receiving endpoint you should use the Robust In-Only. In my opinion, and reading the javadoc seems like that there is no semantic difference when using send, sendsync, and sendsync with timeout. The sendsync simply suspend the thread letting you write simpler code. > So you may want to send an InOnly mep synchronously or send an InOut mep > asynchronously. On the other side, if the delivery channel is xa-enabled, you > will never be able to use sendSync on it. > > I dont' know if sending an InOnly synchronously make sense, but sending an InOut asynchronously does, it allow you to do other this waiting for the answer, the servicemix-http component does it. I know that ServiceMix transactional model can be improved on the > configuration side, and that it involves for a given component to be able to > use both asynchronous and synchronous model, but I don't see how your > proposal would enhance the possible use cases covered, as it is the > opposite in my mind. > My hope is to find a shared point of view. > Comments ? > > > > > > > ------------------- > > > > thanks > > Raffaele > > [EMAIL PROTECTED] > > > > > >
