[DBIx-Class-Devel] [dbix-class] Don't rollback when TxnScopeGuard dtor is run twice (#63)

[Peter Rabbitson]

```
I didn't know this before investigating this issue, but a Perl destructor being called
twice is not an oxymoron at all. All it takes is that the destructor stores another
reference to the object being destroyed in some location that outlives the destructor.
```

What you are describing is the *DESTROY-abort* technique, which DBIx::Class has been relying on to handle its leakless circular refs for about 4 years now. The problem is that as you state **all it takes is that the destructor stores another reference** - this means that something has to "around"  *DBIx::Class::Storage::TxnScopeGuard::DESTROY()* itself, and I can not find this code in Devel::StackTrace.

Could you please point me to what I am missing?

Wrt your "it wouldn't hurt" comment - no it would not hurt. It would also leave broken state out there in the wild, while having DBIC silently working around it. If such code (wrapping DESTROY) indeed exist, and behaves as you describe - it is **very dangerously** broken, and DBIC needs to start warning very loudly when it encounters this problem.

For comparison please see https://github.com/dbsrgits/dbix-class/commit/841efcb3f#diff-c13797cc2e5864c4a1d6a92ba65871b6R81. The original proposal was *why don't we just "$@" and be done*, which I refused to do and went out to write the linked piece instead.

I **will** write the same carefully worded shim for your issue, as soon as I understand which piece of the puzzle is actually causing it. This is how we make CPAN better as a whole ;)

---
Reply to this email directly or view it on GitHub:
https://github.com/dbsrgits/dbix-class/pull/63#issuecomment-60511977
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scsys.co.uk/pipermail/dbix-class-devel/attachments/20141026/565ee088/attachment.htm>