Hi,
Heikki Linnakangas wrote:
> Danny Milosavljevic wrote:
>
>> > The "only" missing
>> > part is an transaction manager, but that wouldn't have to
>> > be integrated into postgres. [...]
>>
>> Our parent company, Fabasoft, already wrote a transaction manager
>> ("Fabasoft Transaction Manager"). I doubt that it is Open Source but
>> I'll ask.
>
>
> Are you a Java shop, using JTA, or are working with a X/Open XA spec
Fabasoft is an e-Government Document Management Provider, who has
Administration Offices and such as customers (who need looong retention,
search, versioning, signatures, paranoid access control, access logging,
custom forms and so on).
Fabasoft has its own object/components model and uses C/C++/Javascript
code to implement methods there (the kernel is in C++). While it is
possible to use a Java or dotnet gate to access it, I don't think that
they are actually using those in production systems (at least not in the
parts not written by the customers themselves).
> compliant interface? If the former, I'd strongly suggest not to invent
> the wheel again. Implementing a transaction manager reliably and
> efficiently isn't as easy as it looks, and there's plenty of open source
> JTA implementations available.
Good to know, but the whole software already works fine for years in an
Fabasoft Components -> Fabasoft Transaction Manager -> Oracle Database
setting (with Distributed Transactions), so its not like we are starting
anew :)
From what I gather even PostgreSQL as it is now could be sufficient if
the Transaction Manager were to use a protocol (like Pgsql-JDBC) does to
talk to PostgreSQL.
>
>> [prepared transactions persist after a crash]
>> [not to complete PREPARED transactions unilaterally]
>
> We have all that in PostgreSQL.
>
>> [time slices]
>
> We don't support that in PostgreSQL. That's what the thread on
> pgsql-jdbc was all about. There's been a lot of discussion on this, and
> the conclusion is: there's isn't anything interesting you can't do
> without it, and implementing it would require huge changes. What we have
> is sufficient for reliable distributed transaction.
Yes, I think so, too. In fact, I'm off to a meeting with management to
see whether that is fine. We'll see.
> After PREPARE TRANSACTION, the transaction is disassociated from the
> connection, and it'll stay prepared even after a server crash.
Very nice.
regards,
Danny Milosavljevic
