Absolutely no need for a long running transaction in the given example.
start tx, insert rec, delete rec, commit tx.
(much better to call a stored procedure or a server function for this)
Back to top      

Unlikely. These monkeys can't even craft reasonable client code, or simple application code which sits on top of the physics engine. Can you imagine anyone who ever worked for Turbine having the technical ability to craft any kind of viable OODBMS?

A lot of, if not all short running timers (cooldown and buff duration) are implemented on the client only.
Could be a nice project to mess around with these things.
Make the Endless Fusilade endless.

Had the idea to write some words about the technical background of exploits, so here's my point of view.

Nearly all exploits are based on the simple fact, that DDO does not have a transactional database management system (DBMS).
Of course i can't prove this fact, but i worked a very long time in software architecture, specialized in distributed DBMS systems and had to fight similar bugs (exploits).

I don't know what these guys are using, but it's surely not a SQL based system, it smells like a homebred OODBMS for object persistence, which means you have to code every single query, no easy scripts for fixes or reports.
Further there are also no relation based structures, i'm sure the whole system is a hardcoded OOP hell without any second thought on a multi-tier architecture.

To the core:
A database transaction is generally atomic. That means, it is either done completely, or it is not done.
To move an item from the bag to the shared bank you will have to modify two places (let's call them tables for simplicity) in the storage system.
In table A (the bag) one record (the item) will be deleted, in table B (the shared bank) one record (the item) will be inserted.
In a healthy DBMS you just start a transaction, do what ever is needed, fire a commit if all is ok and both tables are changed.
If your connection will break between the operations, the DBMS will do an automatic rollback, no table is changed.
Notice something? All exploits based on DC'ing interrupt the coded operations and leave one table in inconsistent state.

The newest changes in DDO paint a disgusting picture about the DDO codebase.
The devs have started to fix the exploits in the client ("exclusive windows").
This is terrible, since this will leave the DDO server system buggy and massacre the user interface to the annoyance of all players.
This is terrible, since it proves that noone at turbine is brave or skilled enough to change the server code.
This is terrible, since it leaves the system wide open for a "man in the middle" attack.
This is terrible, the ultimate exploit tool just needs to capture and modify/resend messages from the client to the server.

Be creative 

And now for the Turbine readers:
There is one simple solution to fix the given "move item" security hole:
Remove the clientbased code sequences and implement a server based new function MoveItem(item, fromContainer, toContainer). No need to touch your barely running system, just an additional function.
And now search for a developer brave and skilled enough to change your network api and remove the retarded exclusive window shit.

Go read up on isolation level next time before posting.  Throwing around terms like "atomic transactions" doesn't mean jack shit.

First you will have to tell me what influence isolations levels could have in a scenario, where only one client instance will touch the data.
Throwing around "isolation level" in a case without concurrent activity on the same record is like a discussion about sex in group of virgins, laughable.  

jeez, are you guys applying for a job at turdbine and want to impress them with your knowledge?