I have an object which wraps some DB interaction with a destructor that sets a particular database column if the object's destructor was called while the object was in an "unclean" state. This is especially useful to know if I received a SIGTERM or somesuch while I was trying to manipulate the object. Specifically I update a status indicator from "Working" to "Aborted"
I'm having trouble getting the desctructor to work properly. Sometimes the database handle gets destroyed before my object's destructor is called and I get a cascade of errors.
Is there any good method to keep the database open somehow until all of my object's destructors are called? The database reference is currently a package scoped my variable. I tried putting a reference to it in every object instance, but it still went away at inconvenient times.
I suppose I could maintain a list of objects and walk the list calling destructors (or a cleanup method) when I receive a TERM signal. That seems unclean and probably wrong. It also won't catch error cases when my object was destroyed (i.e. went out of scope) in other cases due to programming errors.
Is there any way to accomplish this or am I asking too much of the perl interpreter at shutdown time?
Edit:Yea, the design does fail hard for now. I'm working towards redesiging the application. The reason I havent used transactions is that this perl process communicates the status of the object to the frontend website via the status column. Therefore I need to commit so the website sees the new data and the working state. If the perl process aborts I'd like to set the status to 'Aborted' or 'Failed'. Now it just stays in the 'Working' state.
In reply to Object Destructors and Signals by bot403
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |