On Sat, 2 Jul 2005, Oliver Jowett wrote:
Sorry to keep beating on this, but I still don't see where the spec says
that you must have only one RM per transaction branch.
Sure, it's important to get this right.
2.2.6 says:
2.2.6 Transaction Branches
A global transaction has one or more trans
It certainly helps if you need to debug a process.
Ken
On Fri, Jul 01, 2005 at 09:06:03PM +0300, Heikki Linnakangas wrote:
> On Fri, 1 Jul 2005, Oliver Jowett wrote:
>
> >PS: noticed in passing: psql's help doesn't seem to know about the 2PC
> >command syntax yet.
>
> True.
>
> Should we add s
Heikki Linnakangas wrote:
> On Fri, 1 Jul 2005, Oliver Jowett wrote:
>>
>> That implies it's valid (in fact, normal!) to enlist many different RMs
>> in the same transaction branch. Am I interpreting that correctly?
>
>
> I see. No, I don't think that's the correct interpretation, though now
> th
Tom Lane wrote:
> regression=# \h commit prepared
> Command: COMMIT PREPARED
> Description: commit a transaction that was earlier prepared for two-phase
> commit
>
> Syntax:
> COMMIT PREPARED transaction_id
Ah, I was looking under '\h commit', '\h prepare' etc.
-O
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> On Fri, 1 Jul 2005, Oliver Jowett wrote:
>> PS: noticed in passing: psql's help doesn't seem to know about the 2PC
>> command syntax yet.
> True.
Really?
regression=# \h commit prepared
Command: COMMIT PREPARED
Description: commit a transactio
On Fri, 1 Jul 2005, Oliver Jowett wrote:
PS: noticed in passing: psql's help doesn't seem to know about the 2PC
command syntax yet.
True.
Should we add support for it? 2PC is not something you normally do
interactively...
- Heikki
---(end of broadcast)-
Heikki Linnakangas wrote:
> On Fri, 1 Jul 2005, Oliver Jowett wrote:
>
> > PS: noticed in passing: psql's help doesn't seem to know about the 2PC
> > command syntax yet.
>
> True.
>
> Should we add support for it? 2PC is not something you normally do
> interactively...
Yes, we should add psql
On Fri, 1 Jul 2005, Barry Lind wrote:
I oversimplified a bit. The TM *can* enlist multiple threads of control
(= connection in JTA) to the same transaction branch. That's called
"tightly-coupled threads", and they should then be treated as one
local transaction in the RM. The calls will look lik
On Fri, 1 Jul 2005, Oliver Jowett wrote:
What I'm confused about is, for example, 3.3.1 in the DTP:XA spec:
3.3.1 Registration of Resource Managers
Normally, a TM involves all associated RMs in a transaction branch. (The TMs
set of
RM switches, described in Section 4.3 on page 21 tells the T
>>> branch id: Branch Identifier. Every RM involved in the global
>>> transaction is given a *different* branch id.
>>
>> Hm, I am confused then -- the XA spec definitely talks about
enlisting
>> multiple RMs in a single transaction branch.
>>
>> Can you explain?
>
>I oversimplified a bit. The TM *
Heikki Linnakangas wrote:
> On Fri, 1 Jul 2005, Oliver Jowett wrote:
>
>> Heikki Linnakangas wrote:
>>
>>> branch id: Branch Identifier. Every RM involved in the global
>>> transaction is given a *different* branch id.
>>
>>
>> Hm, I am confused then -- the XA spec definitely talks about enlisting
On Fri, 1 Jul 2005, Oliver Jowett wrote:
Heikki Linnakangas wrote:
branch id: Branch Identifier. Every RM involved in the global
transaction is given a *different* branch id.
Hm, I am confused then -- the XA spec definitely talks about enlisting
multiple RMs in a single transaction branch.
On Fri, 1 Jul 2005, Oliver Jowett wrote:
Ok, so how do we get XA working when a single global transaction
involves two databases on the same cluster?
The scenario is:
- there are two independent resource managers participating in a single
global transaction
- each resource manager has a connec
Oliver Jowett wrote:
> Tom Lane wrote:
>
>>It's the TM's responsibility to deal with that. I would expect it to
>>hand out transaction IDs that consist of a common prefix and a
>>per-database suffix, if it does not know which resources it's dealing
>>with might share a common GID namespace.
> I
Tom Lane wrote:
> Oliver Jowett <[EMAIL PROTECTED]> writes:
>
>>Ok, so how do we get XA working when a single global transaction
>>involves two databases on the same cluster?
>
>
> It's the TM's responsibility to deal with that. I would expect it to
> hand out transaction IDs that consist of a
Oliver Jowett <[EMAIL PROTECTED]> writes:
> Ok, so how do we get XA working when a single global transaction
> involves two databases on the same cluster?
It's the TM's responsibility to deal with that. I would expect it to
hand out transaction IDs that consist of a common prefix and a
per-databa
Tom Lane wrote:
> Oliver Jowett <[EMAIL PROTECTED]> writes:
>
>>Can we make the GID-to-internal-xid mapping for prepared transactions
>>1:N rather than the current 1:1?
>
>
> No.
Ok, so how do we get XA working when a single global transaction
involves two databases on the same cluster?
The sc
Oliver Jowett <[EMAIL PROTECTED]> writes:
> Can we make the GID-to-internal-xid mapping for prepared transactions
> 1:N rather than the current 1:1?
No.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our
Dave Cramer <[EMAIL PROTECTED]> writes:
> Do the transaction id's used in 2PC need to be unique across all
> sessions?
> Do we provide a mechanism for this ?
> If not shouldn't we provide a way to create a unique transaction id ?
I see no value in that at all. The point of 2PC is to synchronize
On 30-Jun-05, at 8:00 PM, Oliver Jowett wrote:
Dave Cramer wrote:
I'm thinking of the situation where one transaction occurs on
more than
one backend, and there is
more than one transaction manager.
XA XIDs are *global* IDs, i.e. they are unique even with more than one
TM involved. It's
Oliver Jowett wrote:
> If you have two different databases involved in the same global
> transaction, then yes, the two backends could be told to use the same
> global XID. That's normal. (they don't *have* to be given the same XID
> as they could be participating in two independent branches of th
Dave Cramer wrote:
> I'm thinking of the situation where one transaction occurs on more than
> one backend, and there is
> more than one transaction manager.
XA XIDs are *global* IDs, i.e. they are unique even with more than one
TM involved. It's the responsibility of the TM to generate a
globall
I'm thinking of the situation where one transaction occurs on more
than one backend, and there is
more than one transaction manager.
Dave
On 30-Jun-05, at 7:37 PM, Oliver Jowett wrote:
Dave Cramer wrote:
Do the transaction id's used in 2PC need to be unique across all
sessions?
They a
Dave Cramer wrote:
> Do the transaction id's used in 2PC need to be unique across all sessions?
They are global IDs, yes.
> Do we provide a mechanism for this ?
>
> If not shouldn't we provide a way to create a unique transaction id ?
Well, in XA the XIDs are assigned by the TM, the individual
In reality all it takes is a sequence, however if it were system
generated it would be simpler
Dave
On 30-Jun-05, at 6:46 PM, Alvaro Herrera wrote:
On Thu, Jun 30, 2005 at 06:39:43PM -0400, Dave Cramer wrote:
Do the transaction id's used in 2PC need to be unique across all
sessions?
Yes.
On Thu, Jun 30, 2005 at 06:39:43PM -0400, Dave Cramer wrote:
> Do the transaction id's used in 2PC need to be unique across all
> sessions?
Yes.
> Do we provide a mechanism for this ?
Huh, the constraint is enforced by the server, but the ID is generated
by the client.
> If not shouldn't we p
Do the transaction id's used in 2PC need to be unique across all
sessions?
Do we provide a mechanism for this ?
If not shouldn't we provide a way to create a unique transaction id ?
Dave Cramer
[EMAIL PROTECTED]
www.postgresintl.com
ICQ #14675561
jabber [EMAIL PROTECTED]
ph (519 939 0336 )
27 matches
Mail list logo
