On 12/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 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.
This is a wrong assumption. First make sure you have understood the informations at http://servicemix.goopen.org/site/transactions.html The servicemix flow choosen for a given exchange depends on its QoS which are defined by 4 parameters: persitent, synchronous, transactional, remote. A single exchange must / will always use the same flow, but an endpoint acting as a consumer which will receive this exchange may create and send another one with different QoS, hence another flow may be chosen for this exchange. For example, a consumer endpoint may receive a synchronous transactional exchange, which means that it has to answer in the same transaction. But before sending the answer, it may create and send an exchange asynchronously in the same transaction. The exchange will only be delivered after the transaction has been committed of course. The current behavior has the benefit that the delivery channel may be considered as a transactional resource itself (when exchanges are sent asynchronously) or that the transaction will be conveyed and given to other components. The main problem with the transactional model proposed at the end of the JBI spec, is that it can not be really implemented: it says that the transaction is always conveyed with the exchange, even when the exchange is send asynchronously. The problem is that the number of times the exchanges is sent between the consumer and the provider can be odd or even. So that when the exchange is finished, the transaction may be at the consumer side or at the provider side. I don't think this is usable at all. What if the consumer want to send two different exchanges in the same transaction ? The component starting the transaction must always be the one that will commit it.
> > > > 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.
You can always send a non transactional exchange when inside a transaction. This is not easy currently (most of the components assume that the autoEnlistInTransaction is set), but the fact that an exchange is transacted is controlled by setting the transaction on it. Keep in mind that the QoS of an exchange can not currently be easily configured without changing the code, but this does not imply that ServiceMix does not support it.
> 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.
I do disagree for several reasons. First, the difference between Robust-In-Only and In-Only is that the robust-in-only can reply with a fault (both can end an exchange with an ERROR status). But a fault should only be used for business exceptions, not connection / protocol exceptions. For example, you may want to send an InOnly to a JMS BC (send a jms message) or a JDBC BC (insert a data in a DB). Both may have connections problems (JMS broker or DB down) which should result in an ERROR, not a fault. In the JDBC case, a fault may be sent back (if a robust-in-only was used) if a unique key constraint was violated. You need to abstract a bit from the JBI spec, as the whole spec assumes that the delivery channel will never be a transactional resource itself. Remember, that if the DC is transactional, you can not use sendSync at all.
> 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.
As said earlier, an InOnly can be ended by an ERROR status, which could cause the transaction to be rolledback, whereas a fault for an RobustInOnly or InOut would not (the fault need to be sent back to the consumer). should be sent back to the
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.
Me too ;) -- Cheers, Guillaume Nodet
