r they didn't. (Not that Python core is necessary
- maintaining the test suite in tandem with the spec has worked out ok
so far even if it does lag behind major Python releases).
--
Stuart Bishop
http://www.stuartbishop.net/
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
es.
I personally feel that an Xid() constructor makes things more readable. It
also means we can have driver specific defaults for the format id rather
than no default.
tpc_begin(Xid('foo', 'bar', 1)) vs. tpc_begin(('foo',
id, branch id).
I wouldn't say 'may be worthwhile'. I'd go for 'is essential'. If you can't
inspect the results from tpc_recover(), the method is pointless.
--
Stuart Bishop <[EMAIL PROTECTED]>
http://www.stuartbishop.net/
signature.asc
Description: OpenPGP digital signature
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
>
> Modules should only expect to find an object that behaves like
> a 3-sequence, they should accept whatever object is passed to
> them and return it for the recover method.
>
> This leaves the door open for extensions used by the TM for XID
> objects.
I don't see
n XA like interface around this, how can a
transaction manager filter out the irrelevant XIDs if is cannot interrogate
them?
If behaviour of the xids returned by tpc_recover is not defined, we need
another method to decompose an xid into its global transaction id and its
branch id.
James Henstridge wrote:
> On 22/01/2008, Stuart Bishop <[EMAIL PROTECTED]> wrote:
>> It seems that the formatID is unnecessary and just a requirement of the XA C
>> interface. Also, the xid() method you propose should be camelcase to match
>> the other type constructor
melcase to match
the other type constructors, so Xid(gtrid, bqual=None) or
TransactionId(gtrid, bqual=None). If the xa_recover/list_prepared method
returns TransactionId objects they can contain platform specific information
too which is great (username, prepared timestamp & database
need changes. I
believe this is why in PostgreSQL you declare you are using 2PC at the end
of your transaction and why MySQL offers you the XA COMMIT xid ONE PHASE option.
--
Stuart Bishop <[EMAIL PROTECTED]>
http://www.stuartbishop.net/
signature.asc
Description: OpenPGP digital signature
ids can make
your life easier at 2am).
--
Stuart Bishop <[EMAIL PROTECTED]>
http://www.stuartbishop.net/
signature.asc
Description: OpenPGP digital signature
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
on manager. We just need driver authors
to provide the building blocks for DB-API connections to be integrated with
transaction managers.
--
Stuart Bishop <[EMAIL PROTECTED]>
http://www.stuartbishop.net/
signature.asc
Description: OpenPGP digital signature
le to do the same trick with Oracle, allowing you to handle
more than 2 Oracle connections safely.
--
Stuart Bishop <[EMAIL PROTECTED]>
http://www.stuartbishop.net/
signature.asc
Description: OpenPGP digital signature
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
t()
conn = connect([...])
[... do work ...]
try:
trans = PreparedTransaction(con, 'xid%f' % random())
[... prepare other participants ...]
except:
trans.rollback()
else:
trans.commit()
--
Stuart Bishop <[EMAIL PROTECTED]>
http://www.stuartbishop.net/
M.-A. Lemburg wrote:
> Stuart Bishop wrote:
>> Hi.
>>
>> Are there any drivers out there that support two phase commit.
>>
>> If so, what syntax do they use?
>
> I'm not aware of any native driver that does support this, except a
> patched DCOracl
incompatibilities between backend
specific database APIs.
--
Stuart Bishop <[EMAIL PROTECTED]>
http://www.stuartbishop.net/
signature.asc
Description: OpenPGP digital signature
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listi
14 matches
Mail list logo
