Hrm. You could certainly store the data in stable storage, like with DB_File, though that would have a performance cost. On the other hand, I've never seen a die that eval didn't deal with properly...
| [reply]
[d/l]
[select] |
Yeah, the performance cost is why I only update the DB after a successful send, and then only with basic info, not all the different pkt type counts.
As for the eval{}, feel free to try it on the above code. What seems to happen (as per the results above) is that it can't handle repeated failures ie if MySQL doesn't come back quickly, it survives 1 or 2 DB related errors, but finally keels over, even if used with SIG{__DIE__}.
If you can prove me wrong I'd be ecstatic :-) .
I've also tried putting the eval around just the SQL cmd block ie from SELECT ... to ... finish, without success.
| [reply] |
Yeah, the performance cost is why I only update the DB after a successful send, and then only with basic info, not all the different pkt type counts.
You could consider using a shared memory segment or mmap'd file for this sort of information; they're very fast, but the OS can provide persistence even if your process dies.
As for the eval{}, feel free to try it on the above code.
Well, the code below worked for me reliably over a few hundred connects...
| [reply]
[d/l]
[select] |