Skip site navigation (1) Skip section navigation (2)

Re: Psycopg2 and LIXA

From: Federico Di Gregorio <fog(at)dndg(dot)it>
To: psycopg(at)postgresql(dot)org
Subject: Re: Psycopg2 and LIXA
Date: 2012-02-13 08:52:26
Message-ID: 4F38CF4A.7060507@dndg.it (view raw or flat)
Thread:
Lists: psycopg
Hi Christian,

On 12/02/12 23:02, Christian Ferrari wrote:
[snip]
> (2. and 3. can be swapped if necessary)
> This is one of the key aspects of TX: the connection must be opened by the Transaction Manager, the configuration necessary to open the connection must be managed by the system engineers in charge of the Transaction Manager.
> When you use TX, you don't have to know how the Resource Managers will be reached. TX standard does not specify how the Transaction Manager implements the behavior, it only specifies it's a task of the Transaction Manager.
> LIXA implementation uses a flexible approach: a configuration file contains some profiles, every profile references a set of Resource Managers and theirs configurations. If the Application Program does not specify the LIXA_PROFILE environment variable, it will use the default (first) available profile; if the Application Program specifies the LIXA_PROFILE environment variable, it will use the desired profile. Some commercial Transaction Managers does not allow such flexibility: they behave like LIXA with a single configured profile.
> The X/Open (TX) standard specifies the connection must be opened by the Transaction Manager for many reasons; there are at least two really important reasons:
> 1. the Resource Manager can not be used independently by the Transaction Manager (an Application Program could create a session, perform some work and then pass it to the Transaction Manager creating a potential inconsistent state)
> 2. the Transaction Manager inspects the Resource Managers at tx_open() time to perform automatic recovery of previous prepared/recovery pending transactions
>
> The method "lixa_pq_get_conn()" is a work-around necessary for PostgreSQL and MySQL (lixa_my_get_conn()). Oracle and DB2 do not need such a work-around: they supply specific API; PostgreSQL and MySQL *do* *not* *implement* *standard* *XA*, but only some proprietary extensions that can be used to arrange an XA like interface (LIXA provides that stubs too).

To put it bluntly, I don't like this kind of design at all and I can 
anticipate that just like me other Python programmers wouldn't like it 
too. If you need a work-around (lika_pq_get_conn()) I don't see why not 
provide an hook to register a connection; i.e., lixa_pg_set_conn() or 
something like that. LIXA is conceptually above database adapters 
(should know about their semantics) so it does make sense for it to know 
about psycopg, not the reverse.

Anyway what we can do is to exporse (from C? from Python?) a connection 
function that takes a void* and converts it to a PGconn*. It isn't solid 
and I still don't like it but it is something that should work.

The ideal solution would be for the LIXA Python adapetr to know about 
psycopg (and other adapters) and accept a native Python object to be 
added to the current resource list.

federico


In response to

psycopg by date

Next:From: Daniele VarrazzoDate: 2012-02-13 09:10:33
Subject: Re: Psycopg2 and LIXA
Previous:From: Christian FerrariDate: 2012-02-12 22:02:58
Subject: Re: Psycopg2 and LIXA

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group