Thread: question about implementing XA-ish functions

question about implementing XA-ish functions

From
Theo Schlossnagle
Date:
I'm trying to implement a function that has some XA like properties.

Is it possible to write a postgres extension function that fires when called within a pg transaction... however, the
actionsit takes need to be later committed or rolled back based on the containing transactions commital or not.  Not
havinglooked to deeply into this, I'm wondering if this is possible.  Naively, my first hookpoint would be something
like:

allocate something in the transactions memory context and register a cleanup.... do my work.

when the transaction memory context is cleaned up, my cleanup handler fires, I detect whether the txn was committed or
rolledbackand rightly mark my work as committed or rolled back. 

Thoughts?

--
Theo Schlossnagle
http://omniti.com/is/theo-schlossnagle
p: +1.443.325.1357 x201   f: +1.410.872.4911







Re: question about implementing XA-ish functions

From
Heikki Linnakangas
Date:
Theo Schlossnagle wrote:
> I'm trying to implement a function that has some XA like properties.
> 
> Is it possible to write a postgres extension function that fires when called within a pg transaction... however, the
actionsit takes need to be later committed or rolled back based on the containing transactions commital or not.  Not
havinglooked to deeply into this, I'm wondering if this is possible.  Naively, my first hookpoint would be something
like:
> 
> allocate something in the transactions memory context and register a cleanup.... do my work.
> 
> when the transaction memory context is cleaned up, my cleanup handler fires, I detect whether the txn was committed
orrolledback and rightly mark my work as committed or rolled back.
 

See RegisterXactCallback(). And then there's the ResourceOwners, that
you can use to register custom resources for cleanup.

Of course, you'll never be able to make it atomic without 2PC. The
callbacks are executed very soon after after the commit record has been
flushed to disk, so the window is small but it's there.

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com


Re: question about implementing XA-ish functions

From
jesus@omniti.com
Date:
This is perfect. It fires on both commit and rollback? And I can  
determine which?  The system I'm interfacing with has 2PC so it should  
be a pretty tight fit.  Thanks a ton Heikki!

--
Theo Schlossnagle (mobile)
http://omniti.com/is/theo-schlossnagle

On Dec 18, 2009, at 10:34 AM, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com > wrote:

> Theo Schlossnagle wrote:
>> I'm trying to implement a function that has some XA like properties.
>>
>> Is it possible to write a postgres extension function that fires  
>> when called within a pg transaction... however, the actions it  
>> takes need to be later committed or rolled back based on the  
>> containing transactions commital or not.  Not having looked to  
>> deeply into this, I'm wondering if this is possible.  Naively, my  
>> first hookpoint would be something like:
>>
>> allocate something in the transactions memory context and register  
>> a cleanup.... do my work.
>>
>> when the transaction memory context is cleaned up, my cleanup  
>> handler fires, I detect whether the txn was committed or rolledback  
>> and rightly mark my work as committed or rolled back.
>
> See RegisterXactCallback(). And then there's the ResourceOwners, that
> you can use to register custom resources for cleanup.
>
> Of course, you'll never be able to make it atomic without 2PC. The
> callbacks are executed very soon after after the commit record has  
> been
> flushed to disk, so the window is small but it's there.
>
> -- 
>  Heikki Linnakangas
>  EnterpriseDB   http://www.enterprisedb.com