I've posted a newer revision here:
I modified the implementation of recover to put the recovered xid's in the
transaction state map so that they'll be there when the tm tries to commit
or roll them back.
I renamed some variable and class names to take them a little closer to
their actual meaning.
I added small amount of code documentation. Much more to come.
I think I made some other minor adjustments which I've forgotten.
On Thu, 21 Jul 2005, Heikki Linnakangas wrote:
> So far so good. You still have all the same tough issues ahead as I do,
> I realize it's work in progress, but here's some comments in no particular
> 1. To answer the question in the source code: PostgreSQL doesn't support
> transaction timeouts
> 2. Using prepared statements like "PREPARE TRANSACTION ?" won't work. You can
> only use prepared statements for normal SELECT/UPDATE/DELETE commands.
> 3. How are you planning to handle transaction interleaving discussed in the
> thread Dave mentioned?
> 4. recover is broken because it ignores the flags argument. That's going to
> cause an endless loop in the transaction manager when it tries to recover.
> See this discussion:
> 5. commit and rollback check that the transaction is found in
> XID_TO_TRANSACTION_STATE_MAP. However, after a crash/recover cycle, the map
> will be empty.
> 6. isSameRM considers two connections to the same database as different RMs.
> I'm not sure what the implications of this are, but I feel that's not right.
> I have the same issue in my implementation as well...
> Also take a look at a list of comments on my code by Mike Bonnet. Some of
> them probably apply to your code as well. Those comments are about the
> version that's on my pg webpage:
> The XA and JTA specifications are quite complicated. I'd like to see a good
> set of test cases that exercise all possible scenarious and also error
> conditions. We're also going to need testers with access to the popular
> application servers so that we know our implementation works with them.
> AFAIK, the only open source application server that does recovery properly is
> the CVS head version of JOnAS.
> Also, if we violate some parts of the specs (like the transaction
> interleaving part), it's important to know exactly what the limitations are
> and why. I started to write down the exact preconditions for each method in
> the javadoc comments, and also separate which preconditions come from the
> specs and which are just implementation-specific limitations.
> On Wed, 20 Jul 2005, Michael Allman wrote:
>> Here's my first cut:
>> At this point I know the documentation is sparse. I'll try to improve that
>> situation soon. Until then, I wanted to give everyone the opportunity to
>> take a first look at the code and the approach.
>> I also have some questions, some of which are embedded in the .java files
>> as comments. If anyone has answers, please pass them along.
>> I'll let you chew on this and check back tomorrow.
>> On Wed, 20 Jul 2005, Heikki Linnakangas wrote:
>>> I'm working on it. Glad to hear your interested. I don't have much time to
>>> work on it though, so I would be very happy if you took over.
>>> I'll send you a copy of my workbench off-list so you can take a look. It's
>>> work in progress, but I hope it helps..
>>> I believe this is the discussion Dave mentioned:
>>> - Heikki
>>> On Tue, 19 Jul 2005, Dave Cramer wrote:
>>>> Not sure, but look at the archives, there was some discussion about
>>>> various mechanism.
>>>> On 19-Jul-05, at 7:34 PM, Michael Allman wrote:
>>>>> I'm implementing XA support in the postgres JDBC driver to complement
>>>>> the backend two phase commit support in CVS. Is anyone else working on
>>> ---------------------------(end of broadcast)---------------------------
>>> TIP 4: Have you searched our list archives?
> - Heikki
In response to
pgsql-jdbc by date
|Next:||From: Oliver Jowett||Date: 2005-07-22 01:57:50|
|Subject: Re: Timestamp Conversion Woes Redux|
|Previous:||From: Michael Allman||Date: 2005-07-22 01:04:33|
|Subject: Re: jdbc xa support|