Hi Jonathan,
On Thu, Jun 21, 2012 at 10:49 AM, Jonathan Halliday <
jonathan.halliday_at_redhat.com> wrote:
> I'm averse to anything that requires additional bytes to be forced to disk
> on each transaction. It's not necessary for obtaining the in-doubt list
> from an RM. For that you need only one XAResource for the entire RM, not
> one per tx.
>
I understand your concerns, however I have a different view on those
additional bytes, I think the transaction log should be as self-contained
as possible and
an additional 20-40 byte per transaction don't harm IMO. (I don't disagree
with your suggestion, I just want to explain, why I don't share your
concerns
regarding some extra bytes)
To provide some background, why I think like that:
The Versant Database, although supporting XA, does also provide a complete
own, independent implementation of the 2-phase-commit protocol.
The roles and responsibilities differ a bit from XA, and both of course
differ a bit from the generic 2PC discussion in
Bernstein/Hadzilacos/Goodman.
When using the native Versant 2PC, out of n involved databases, one is the
"coordinator", which also serves the role of being the transaction
managers log file and (n-1) databases are "participants", actually these
roles are assigned per transaction, and one database might be the
coordinator
of txn1 and at the same time it can be the participant of txn2.
In each transaction-begin log record we store the name of the coordinator,
which can be asked after a system failure about this particular
transaction's outcome.
Over the last years - although this might change with the advent of SSDs -
the fsync() rate of harddisks proved to be the limiting factor as long as
the to-be-written data do not exceed a track-length or so.
So even in our log-files, which contain a mix of transaction coordinator
and real transaction log records, these few additional bytes did not make
the
difference, in a dedicated log file of a transaction manager I think the
effect is negligible (but I have not explictly tested this though)
What we have introduced to overcome this problem is double-buffering of the
transaction log file.
This means, one half of the log file buffer is active. Naturally, only
certain types of log-file entries require an fsync(), while others
are simply appended to the buffer.
Once an fsync-requiring entry occurs, the other half of the buffer becomes
active while the first half is flushed to the disk.
Any thread writing an fsync-requiring entry to the now-active half, will
have to wait, while the flushing of the first half is still being executed.
Effectively, in high-concurrent scenarios, multiple threads are waiting and
once it's time to switch buffer halfs again, all those
fsyncable records are written in one go.
This means we reach a much high transaction rate/sec than normally
possible, which (without 2PC) would be just 120 txn/sec for
a 7200rpm disc while still guaranteeing ACID.
What I wanted to explain is, that IMO it's not a few extra bytes which
limit the performance.
interface AnnotatedXAResource extends XAResource {
> byte[] getJNDIName()
> }
>
>
What type of object should the JNDI name refer to?
Regards,
Christian
--
Christian Romberg
Chief Engineer | Versant GmbH
(T) +49 40 60990-0
(F) +49 40 60990-113
(E) cromberg_at_versant.com
www.versant.com<http://www.google.com/url?q=http%3A%2F%2Fwww.versant.com%2F&sa=D&sntz=1&usg=AFrqEzeeEBc_gN_8mxtt8xDB0tjXDXQVlw>|
www.db4o.com<http://www.google.com/url?q=http%3A%2F%2Fwww.db4o.com%2F&sa=D&sntz=1&usg=AFrqEzdo3Q40RwKQPBtnPIuBYQd1diFxJQ>
--
Versant
GmbH is incorporated in Germany. Company registration number: HRB
54723, Amtsgericht Hamburg. Registered Office: Halenreie 42, 22359
Hamburg, Germany. Geschäftsführer: Bernhard Wöbker, Volker John
CONFIDENTIALITY
NOTICE: This e-mail message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential or
proprietary information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient,
immediately contact the sender by reply e-mail and destroy all copies of
the original message.