Some more clarifications about the changes :
when we write a LogEdit, we have two cases :
1) we write a ChangeDataContainer
2) we write a Transaction state
In the first case, we serialize the data in the log( LogEdit, sync)
method using the current transaction logRecord, then we call the log(
UserLogRecord, sync) method which will write the record in the WAL. In
the second case, we simply call the log( UserLogRecord, sync) without
having to grab the current transaction, as we already are dealing with a
transaction. The places where this is done are :
DefaultTxnManager.abortReadWriteTxn
DefaultTxnManager.beginReadWriteTxn
DefaultTxnManager.commitReadWriteTxn
I created a LogEdit.injectData( userLogRecord, type ) to have one single
place to manage the serialization of a LogEdit instance
(ChangeDataContainer ot TxnStateChange) instead of 4, and to be able to
add some log.debug() in one single place instead of 4. This does not
change the logic of this part of the code.
Regarding the added type, as I explained in another mail, I did that to
be sure we can handle cases where we wil have something not expected
like a sequence of TXN_BEGIN/TXN_COMMIT without any DATA_CONTAINER. Here
is an exemple of the trace I get with a simple Add request :
Serializing : TxnStateChange[-9223372036854775808/TXN_BEGIN]
Serializing : TxnStateChange[-9223372036854775804/TXN_COMMIT]
Serializing : TxnStateChange[-9223372036854775808/TXN_BEGIN]
Serializing : DataChangeContainer(ou=system,
866e5898-6aaa-4e84-96f2-c423bb6ef8b2, -9223372036854775808)
{
IndexChange '1.3.6.1.4.1.18060.0.4.1.2.50': <ADD,
866e5898-6aaa-4e84-96f2-c423bb6ef8b2,
ParentIdAndRdn<96512910-d92d-49c4-ac8a-20d28c4ff57c, 'cn=test'>>
IndexChange '2.5.4.0': <ADD, 866e5898-6aaa-4e84-96f2-c423bb6ef8b2,
person>
IndexChange '2.5.4.0': <ADD, 866e5898-6aaa-4e84-96f2-c423bb6ef8b2, top>
IndexChange '1.3.6.1.4.1.18060.0.4.1.2.4': <ADD,
866e5898-6aaa-4e84-96f2-c423bb6ef8b2, 96512910-d92d-49c4-ac8a-20d28c4ff57c>
IndexChange '1.3.6.1.4.1.18060.0.4.1.2.43': <ADD,
866e5898-6aaa-4e84-96f2-c423bb6ef8b2, 866e5898-6aaa-4e84-96f2-c423bb6ef8b2>
IndexChange '1.3.6.1.4.1.4203.666.1.7': <ADD,
866e5898-6aaa-4e84-96f2-c423bb6ef8b2,
20120314234251.077000Z#000000#000#000000>
IndexChange '1.3.6.1.1.16.4': <ADD,
866e5898-6aaa-4e84-96f2-c423bb6ef8b2, 866e5898-6aaa-4e84-96f2-c423bb6ef8b2>
EntryAddDelete : ADD
Entry
dn[n]: cn=test,ou=system
objectclass: person
objectclass: top
cn: test
sn: TEST
entryParentId: 96512910-d92d-49c4-ac8a-20d28c4ff57c
entryUUID: 866e5898-6aaa-4e84-96f2-c423bb6ef8b2
createTimestamp: 20120314234251Z
creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
entryCSN: 20120314234251.077000Z#000000#000#000000
}
Serializing : TxnStateChange[-9223372036854775802/TXN_COMMIT]
I slightly modified some of the read/writeExternal methods too,
especially the one that serailize the index. Call it premature
optimization... At least, those changes are local to those methods.
Hope it helps to understand the changes
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
