On Jan 26, 2006, at 9:27 AM, Perrin Harkins wrote:
ady more optimization than I would do. I just roll back at the end
of every request. If there's nothing to roll back, it shouldn't
take long. However, if you catch your execptions, you'll know when
you've had one, and can roll back then. See below.
I already have a mechanism in place...
This might make some people here cringe, but...
I created a DB class that kind of works like a singleton and
'resets' a connection to the logging db, reading db and writing db
handles, and passes along the current handle for each connection when
asked
each db handle is a member of another class that has the usually
connect/disconnect/params
It also allows for 3 levels of 'transactions' :
Page
Object
Shared Object ( non transactional )
instead of starting a transaction on the DB, i start it on the DB
specifiying a page , object or shared object
This way, on a page, i can chain multiple object transactions -- and
fail the whole set if/when a component transaction dies. The shared
objects are a different class that don't call any transaction start/
end and will not start unless the db handle is in an active transaction
it was a crazy quick hack i thought of a while back to let me make
certain things transaction safe on their own, but then recycle them
into other uses. Its often unnecessary , but its there and keeps a
count of my transaction status
You want to wrap your code in an eval block, catch the exceptions,
and print a stack trace (or just log the stack trace if you're in
production). You can use Carp for this, or Devel::StackTrace.
There are some docs on exception handling:
http://perl.apache.org/docs/general/perl_reference/
perl_reference.html#Exception_Handling_for_mod_perl
Thanks a ton! Thats exactly what I was looking for.
