view release on metacpan or  search on metacpan

configuration/dbconf/globalconf.pl  view on Meta::CPAN

# (as the DESTROY is the last to be called even in Apache::BabyConnect)
# In either case, whenever DESTROY is called, if the autorollback is 1 and autocommit is 0
# and the DBI execute has returned with failure, then the rollback is in effect.

# The caller can always catch and check the return value of a DBI::BabyConnect method
# to see if it has failed a DBI execute. Typically DBI::BabyConnect methods return undef
# whenever a DBI execute fails and therefore the caller can check the return
# value and decide on whether to call the DBI::BabyConnect object method rollback himself or not,
# therefore allowing the caller to continue to work with the instance of DBI::BabyConnect object 
# and its open DBI connection.
# Yet, you can configure the behavior of the DBI::BabyConnect object methods globally
# and tell the object methods to automatically rollback and exit on failure.

# This option is settable and will work only if AutoRollback is in effect for the
# DBI, because DBI::BabyConnect objects delegate all rollbacks to the DBI itself.
# DBI rollback is in effect if and only if:
#  RaiseError is 0 (it should be off because otherwise the DBI would have exited earlier due to the error)
#  AutoCommit is 0 (DBI will have no effect on rollback is AutoCommit is set to 1)
# DBI::BabyConnect will keep track of the success or failure of DBI execute(), hence deciding on
# what to do on failure.
#

eg/README  view on Meta::CPAN

   http server will load that new DBI::BabyConnect object and cache it.

   In a random situation where DBI::BabyConnect objects are requested, if you have 4 database
   descriptors to be used, and 8 http servers started, then you end up having each of the
   http server caching 4 database descriptors.
   Two http servers will never share the same DBI::BabyConnect objects.
   If you are reading data from the data sources, then you are doing fine. But if you
   are writing to the database, then you need to know what you are doing.

7- Test the rollback
In globalconf.pl set 
ON_FAILED_DBIEXECUTE_ROLLBACK_AND_EXIT=1
and restart the httpd
this will rollback and exit on error. With Apache::BabyConnect the rollback
is effectively handled by DBI::BabyConnect, and the exit is handled by Apache
MD2. In other word your script will end at that point (after the rollback took
effect)
Test script: testrollback.pl
   Request http://yourserver.com/perl/testrollback.pl

In globalconf.pl set 
ON_FAILED_DBIEXECUTE_ROLLBACK_AND_EXIT=0
and restart the httpd (/etc/rc.d/init.d/httpd restart)
this will neither rollback nor exit on error. In addition
your script will continue past the point of the do()'s. You can
chose to rollback programmatically if you want.
Test script: testrollback.pl
   Request http://yourserver.com/perl/testrollback.pl