You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by lorenzo <la...@sungard.com> on 2012/08/30 11:35:50 UTC

Transaction design for a custom compononent

Hello there,

I am writing a custom camel component which essentially has to record what
it has sent successfully so that it does not resend the same piece of info
twice.

Surely this involves a transactional behaviour. The data is read from a DB
(JDBC) and is sent to a JMS queue. All good in terms of transactional
capabilities.

Now, where do I start and end my transaction ? I was thinking to use the
wireTap EIP and make the whole thing transactional. I am therefore creating
a new point of inflexion in my route.

Now I realize that reading the data, making note that the data has been
read, and publishing it is one same atomic action, it does not make sense to
have one part without the others. So I think it is better to encapsulate all
this in one small chunk.

Anyway, I am not sure what I am suggesting makes any sense, I am open to
suggestions.

Kind Regards



--
View this message in context: http://camel.465427.n5.nabble.com/Transaction-design-for-a-custom-compononent-tp5718361.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: Transaction design for a custom compononent

Posted by Charles Moulliard <ch...@gmail.com>.
Yes.

On Thu, Aug 30, 2012 at 4:11 PM, lorenzo <la...@sungard.com>wrote:

> I ended up writing a custom AbstractJdbcMessageIdRepository which
> essentially
> uses the table I was using previously with my "by-hand" method.
>
> Do you think that can fly ?
>
> (at first sight it does ....)
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Transaction-design-for-a-custom-compononent-tp5718361p5718412.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>



-- 
Charles Moulliard
Apache Committer / Sr. Pr. Consultant at FuseSource.com
Twitter : @cmoulliard
Blog : http://cmoulliard.blogspot.com

Re: Transaction design for a custom compononent

Posted by lorenzo <la...@sungard.com>.
I ended up writing a custom AbstractJdbcMessageIdRepository which essentially
uses the table I was using previously with my "by-hand" method.

Do you think that can fly ?

(at first sight it does ....)



--
View this message in context: http://camel.465427.n5.nabble.com/Transaction-design-for-a-custom-compononent-tp5718361p5718412.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: Transaction design for a custom compononent

Posted by Charles Moulliard <ch...@gmail.com>.
If you look to the following class of the JPA component which is a
idempotentConsumer + Repository you can fetch data from a table to see if
they have already been processed, add to the repository the new one and is
Tx aware

http://svn.apache.org/repos/asf/camel/trunk/components/camel-jpa/src/main/java/org/apache/camel/processor/idempotent/jpa/JpaMessageIdRepository.java

http://camel.apache.org/jpa.html

On Thu, Aug 30, 2012 at 3:03 PM, lorenzo <la...@sungard.com>wrote:

> Hi Charles,
>
> I did not know about this idempotentConsumer, thanks for that.
>
> I wonder if it pays off in my case though, as I have to query the
> repository
> table so I can select things to send out based on what has already been
> sent.
>
> I have done that for now, which I think suffice for my needs:
>
>         @Override
>         protected int poll() throws Exception {
>                 final int numberOfMessagesPolled = 1;
>                 final Exchange exchange = endpoint.createExchange();
>                 final MapObject mapObject =
> mapRepository.pollNextObject(exchange
>                                 .getIn());
>                 try {
>                         getProcessor().process(exchange);
>                         mapRepository.logMessageProcessed(mapObject);
>                         return numberOfMessagesPolled;
>                 } finally {
>                         if (exchange.getException() != null) {
>                                 getExceptionHandler().handleException(
>                                                 "Error processing
> exchange", exchange,
>                                                 exchange.getException());
>                         }
>                 }
>         }
>
> if getProcessor().process(exchange); fails, then I won't log the message as
> being sent. On the other hand if the message is processed, then it is safe
> to store the value.
>
> Chances that the exchange fails after that are small, but existing, so
> probably I have to upgrade my solution to the idempotentConsumer, solely
> for
> having this transactional behaviour...
>
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Transaction-design-for-a-custom-compononent-tp5718361p5718392.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>



-- 
Charles Moulliard
Apache Committer / Sr. Pr. Consultant at FuseSource.com
Twitter : @cmoulliard
Blog : http://cmoulliard.blogspot.com

Re: Transaction design for a custom compononent

Posted by lorenzo <la...@sungard.com>.
Hi Charles,

I did not know about this idempotentConsumer, thanks for that.

I wonder if it pays off in my case though, as I have to query the repository
table so I can select things to send out based on what has already been
sent.

I have done that for now, which I think suffice for my needs:

	@Override
	protected int poll() throws Exception {
		final int numberOfMessagesPolled = 1;
		final Exchange exchange = endpoint.createExchange();
		final MapObject mapObject = mapRepository.pollNextObject(exchange
				.getIn());
		try {
			getProcessor().process(exchange);
			mapRepository.logMessageProcessed(mapObject);
			return numberOfMessagesPolled;
		} finally {
			if (exchange.getException() != null) {
				getExceptionHandler().handleException(
						"Error processing exchange", exchange,
						exchange.getException());
			}
		}
	}

if getProcessor().process(exchange); fails, then I won't log the message as
being sent. On the other hand if the message is processed, then it is safe
to store the value.

Chances that the exchange fails after that are small, but existing, so
probably I have to upgrade my solution to the idempotentConsumer, solely for
having this transactional behaviour...




--
View this message in context: http://camel.465427.n5.nabble.com/Transaction-design-for-a-custom-compononent-tp5718361p5718392.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: Transaction design for a custom compononent

Posted by Charles Moulliard <ch...@gmail.com>.
Hi Lorenzo,

Why are you developing a new component instead of using a
idempotentConsumer (http://camel.apache.org/idempotent-consumer.html) in
the camel which will take care about the data already processed ?

Regards,

Charles

On Thu, Aug 30, 2012 at 11:35 AM, lorenzo <la...@sungard.com>wrote:

> Hello there,
>
> I am writing a custom camel component which essentially has to record what
> it has sent successfully so that it does not resend the same piece of info
> twice.
>
> Surely this involves a transactional behaviour. The data is read from a DB
> (JDBC) and is sent to a JMS queue. All good in terms of transactional
> capabilities.
>
> Now, where do I start and end my transaction ? I was thinking to use the
> wireTap EIP and make the whole thing transactional. I am therefore creating
> a new point of inflexion in my route.
>
> Now I realize that reading the data, making note that the data has been
> read, and publishing it is one same atomic action, it does not make sense
> to
> have one part without the others. So I think it is better to encapsulate
> all
> this in one small chunk.
>
> Anyway, I am not sure what I am suggesting makes any sense, I am open to
> suggestions.
>
> Kind Regards
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Transaction-design-for-a-custom-compononent-tp5718361.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>



-- 
Charles Moulliard
Apache Committer / Sr. Pr. Consultant at FuseSource.com
Twitter : @cmoulliard
Blog : http://cmoulliard.blogspot.com