Originally Posted by
Leaves
Question: using 2), wouldn't the server need to keep track of all such transactions until they clear? and then save them one by one? You mentioned saving on quit, but it would seem risky and a potential source for data loss, especially if there is a certain accumulation of transactions. You don't have to explain, but I'm quite interested, so feel free :P
The transactions are serial, independent of each other and occur in microseconds. They don't accumulate because the only thing they block is themselves. Two characters wouldn't block each other because they're not touching the same rows of data.
An example of how an item moves out of your storage bin into your inventory for example would be;
Code:
INSERT INTO ItemSlot_ETC
SELECT * from ItemLocker where
where characterid = 1 and accountid = 2 and sn = 99999;
GO
DELETE FROM ItemLocker where
characterid = 1 and accountid = 2 and sn = 99999;
The statements between the GO are handled as separate discrete events.
They complete as soon as you pass their semi-colon. If a crash occurs between them, voila, dupe.
It's as simple as this;
Code:
BEGIN TRANSACTION
INSERT INTO ItemSlot_ETC
SELECT * from ItemLocker where
where characterid = 1 and accountid = 2 and sn = 99999;
DELETE FROM ItemLocker where
characterid = 1 and accountid = 2 and sn = 99999;
COMMIT TRANSACTION;
And suddenly the two are a single discrete block of logic. They both write their end results together, or not at all. Voila. Duping no longer possible.
Duping being possible at all is ridiculous.
Bookmarks