Re: Psycopg2 and LIXA

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