Hi Andrea,
Agreed - it's not transparent, it's explicit. You'll need to
explicitly create a JMS consumer to listen off the queue and then
another to put it back onto another queue at the end if necessary. The
benefit is that between these two queues, you can do as much
processing as you like in the context of the same transaction, without
having your message exchanges persisted.
In terms of "re-start": the message will be redelivered automatically
if the transaction was rolled-back or the transaction timed out.
Will this solution work for you?
/Ade
On 18 Nov 2008, at 13:03, Andrea Zoppello wrote:
Hi Adrian,
Thank you for your response, but i cannot understand some point
about your expalnation:
You mean that if i want message persisted i shoud use JMS Input
Binding Component???
I know this work well and that with JMS you could use transactions,
but it's still not very transparent.
On the other side within this approach it's mandatory to "restart"
from the JMS Input Binding component ( Is this right?? ).
Andrea
Adrian Trenaman ha scritto:
Hi Andrea,
I've written about the use of flows at http://trenaman.blogspot.com/2008/11/jmsjca-flows-in-servicemix-wrong-level.html
. Right now SMX4 does not support the JMS or JCA flow, however, I
don't think this is a bad thing at all. To achieve what you want,
you could use a transactional SEDA flow: take your message off an
explicitly named JMS queue in the context of a transaction, and let
the transaction get propagated all the way through till your work
is done. In the event of a failure mid-processing, the message will
still be retained on the queue and will be processed again on
restart.
So, you can achieve what you want by explicitly declaring
transactional queues, rather than letting SMX decide for you. This
has the advantage that our solution is more explicit in terms of
its use of queues and transactions, and that your solution will
perform better because you're not taking the performance hit of
transactionally persisting messages every time something goes over
the NMR.
Hope that helps!
Ade
On 18 Nov 2008, at 11:01, Andrea Zoppello wrote:
BTW i still have some doubt, about it.
Mu main doubt, is about the concept of flow.
As i understand servicemix 4 will support only seda flow ( am i
wrong ?? ) and as i understand, the nmr implementation will not
use activemq as underline implementation, but it still only
support jms style endpoint.
My point is that with old servicemix all messages going through
the nmr was persisted ( we've configured activemq to persist
message ) and if the system go down and then is recovered my
messages were there. Is this guaranteed with servicemic 4??? Are
the messages persisted??
This is a very important feature for us.
Any toughts???
---
Adrian Trenaman, Consultant Fellow, PS - Opensource Center of
Competence
Progress Software Corp
Shelbourne Road, Dublin 4, Ireland
---
+353-1-637-2659 (Office)
+353-1-637-2882 (Fax)
+353-86-6051026 (Mobile)
adrian.trenaman (Skype)
----
Blog: http://trenaman.blogspot.com
---
Adrian Trenaman, Consultant Fellow, PS - Opensource Center of Competence
Progress Software Corp
Shelbourne Road, Dublin 4, Ireland
---
+353-1-637-2659 (Office)
+353-1-637-2882 (Fax)
+353-86-6051026 (Mobile)
adrian.trenaman (Skype)
----
Blog: http://trenaman.blogspot.com
