Re: Psycopg2 and LIXA - Mailing list 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
necessaryto 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
theTransaction 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
setof Resource Managers and theirs configurations. If the Application Program does not specify the LIXA_PROFILE
environmentvariable, it will use the default (first) available profile; if the Application Program specifies the
LIXA_PROFILEenvironment variable, it will use the desired profile. Some commercial Transaction Managers does not allow
suchflexibility: 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
areat least two really important reasons: 
> 1. the Resource Manager can not be used independently by the Transaction Manager (an Application Program could create
asession, 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/recoverypending transactions 
>
> The method "lixa_pq_get_conn()" is a work-around necessary for PostgreSQL and MySQL (lixa_my_get_conn()). Oracle and
DB2do 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