JDBC Connector and Poison Records

[Meeraj Kunnumpurath-3]

Hi,

I have a component that uses a JDBC endpoint. Everything works fine in
the happy path with a read and read.ack SQLs. However, things go for a
spin when there is something wrong in the record and the UMO throws an
exception. The record is continuously retried. Is there anyway, I can
mark the record as invalid in case of the exception. I looked at
defining an exception strategy that has a JDBC endpoint that will mark
the record as invalid. However, since no semantic context is passed from
the inbound endpoint, the catch all endpoint can't identify the record
to be updated.

Even the exception strategy worked, I would prefer a different solution,
since I really want the action take place at the receiver end. This is
because the UMO may have multiple inbound endpoints and marking a record
as invalid using an SQL is relevant only in case of exception occurring
when the input came through a JDBC endpoint. What I am really looking is
something like a read.nack similar to read.ack to fire in case of an
error.

Any pointers would be highly appreciated.

Ta
Meeraj




*****************************************************

    You can find us at www.voca.com

*****************************************************
This communication is confidential and intended for
the exclusive use of the addressee only. You should
not disclose its contents to any other person.
If you are not the intended recipient please notify
the sender named above immediately.

Registered in England, No 1023742,
Registered Office: Voca Limited
Drake House, Three Rivers Court,
Homestead Road, Rickmansworth,
Hertfordshire, WD3 1FX


This message has been checked for all email viruses by MessageLabs.

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Andrew Perepelytsya]

Meeraj,

Maybe, a custom implementation of the IdempotentReceiver may help in the short-term. This way you'll keep track of records already processed and filter out duplicates.

The NACK query may be a good idea, will check if it's possible to do in the future.

Andrew

On 8/16/06, Meeraj Kunnumpurath <M.Kunnumpurath@...> wrote:

Hi,

I have a component that uses a JDBC endpoint. Everything works fine in
the happy path with a read and read.ack SQLs. However, things go for a
spin when there is something wrong in the record and the UMO throws an
exception. The record is continuously retried. Is there anyway, I can
mark the record as invalid in case of the exception. I looked at
defining an exception strategy that has a JDBC endpoint that will mark
the record as invalid. However, since no semantic context is passed from
the inbound endpoint, the catch all endpoint can't identify the record
to be updated.

Even the exception strategy worked, I would prefer a different solution,
since I really want the action take place at the receiver end. This is
because the UMO may have multiple inbound endpoints and marking a record
as invalid using an SQL is relevant only in case of exception occurring
when the input came through a JDBC endpoint. What I am really looking is
something like a read.nack similar to read.ack to fire in case of an
error.

Any pointers would be highly appreciated.

Ta
Meeraj




*****************************************************

    You can find us at www.voca.com

*****************************************************
This communication is confidential and intended for
the exclusive use of the addressee only. You should
not disclose its contents to any other person.
If you are not the intended recipient please notify
the sender named above immediately.

Registered in England, No 1023742,
Registered Office: Voca Limited
Drake House, Three Rivers Court,
Homestead Road, Rickmansworth,
Hertfordshire, WD3 1FX


This message has been checked for all email viruses by MessageLabs.

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Andrew Perepelytsya]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Meeraj,

In the meantime I have filed your wish at http://jira.symphonysoft.com/browse/MULE-977 . Though, I don't think we'll have enough resources to address it in the near future. You can, however, always contribute one :)

Andrew

On 8/16/06, Andrew Perepelytsya <aperepel@...> wrote:

Meeraj,

Maybe, a custom implementation of the IdempotentReceiver may help in the short-term. This way you'll keep track of records already processed and filter out duplicates.

The NACK query may be a good idea, will check if it's possible to do in the future.

Andrew

On 8/16/06, Meeraj Kunnumpurath <M.Kunnumpurath@...> wrote:

Hi,

I have a component that uses a JDBC endpoint. Everything works fine in
the happy path with a read and read.ack SQLs. However, things go for a
spin when there is something wrong in the record and the UMO throws an
exception. The record is continuously retried. Is there anyway, I can
mark the record as invalid in case of the exception. I looked at
defining an exception strategy that has a JDBC endpoint that will mark
the record as invalid. However, since no semantic context is passed from
the inbound endpoint, the catch all endpoint can't identify the record
to be updated.

Even the exception strategy worked, I would prefer a different solution,
since I really want the action take place at the receiver end. This is
because the UMO may have multiple inbound endpoints and marking a record
as invalid using an SQL is relevant only in case of exception occurring
when the input came through a JDBC endpoint. What I am really looking is
something like a read.nack similar to read.ack to fire in case of an
error.

Any pointers would be highly appreciated.

Ta
Meeraj




*****************************************************

    You can find us at www.voca.com

*****************************************************
This communication is confidential and intended for
the exclusive use of the addressee only. You should
not disclose its contents to any other person.
If you are not the intended recipient please notify
the sender named above immediately.

Registered in England, No 1023742,
Registered Office: Voca Limited
Drake House, Three Rivers Court,
Homestead Road, Rickmansworth,
Hertfordshire, WD3 1FX


This message has been checked for all email viruses by MessageLabs.

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Meeraj Kunnumpurath-3]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Thanks Andrew. I am looking into this, if I get something done, I will definitely post it.

---

From: Andrew Perepelytsya [mailto:aperepel@...]
Sent: 16 August 2006 22:59
To: user@...
Subject: Re: [mule-user] JDBC Connector and Poison Records

Meeraj,

In the meantime I have filed your wish at http://jira.symphonysoft.com/browse/MULE-977 . Though, I don't think we'll have enough resources to address it in the near future. You can, however, always contribute one :)

Andrew

On 8/16/06, Andrew Perepelytsya <aperepel@...> wrote:

Meeraj,

Maybe, a custom implementation of the IdempotentReceiver may help in the short-term. This way you'll keep track of records already processed and filter out duplicates.

The NACK query may be a good idea, will check if it's possible to do in the future.

Andrew

On 8/16/06, Meeraj Kunnumpurath <M.Kunnumpurath@...> wrote:

Hi,

I have a component that uses a JDBC endpoint. Everything works fine in
the happy path with a read and read.ack SQLs. However, things go for a
spin when there is something wrong in the record and the UMO throws an
exception. The record is continuously retried. Is there anyway, I can
mark the record as invalid in case of the exception. I looked at
defining an exception strategy that has a JDBC endpoint that will mark
the record as invalid. However, since no semantic context is passed from
the inbound endpoint, the catch all endpoint can't identify the record
to be updated.

Even the exception strategy worked, I would prefer a different solution,
since I really want the action take place at the receiver end. This is
because the UMO may have multiple inbound endpoints and marking a record
as invalid using an SQL is relevant only in case of exception occurring
when the input came through a JDBC endpoint. What I am really looking is
something like a read.nack similar to read.ack to fire in case of an
error.

Any pointers would be highly appreciated.

Ta
Meeraj




*****************************************************

    You can find us at www.voca.com

*****************************************************
This communication is confidential and intended for
the exclusive use of the addressee only. You should
not disclose its contents to any other person.
If you are not the intended recipient please notify
the sender named above immediately.

Registered in England, No 1023742,
Registered Office: Voca Limited
Drake House, Three Rivers Court,
Homestead Road, Rickmansworth,
Hertfordshire, WD3 1FX


This message has been checked for all email viruses by MessageLabs.

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

This message has been checked for all email viruses by MessageLabs.

This message has been checked for all email viruses by MessageLabs.