Selena Deckelmann wrote:
> On Jul 17, 2007, at 2:58 PM, Roderick A. Anderson wrote:
>>> How does/ or does DBI handle row level locks that Postgresql (and I
>> think Oracle) provides. Do they apply to the database handle ($dbh)?
>>>> So if,
>>>> ###
>> my $sth = $dbh->prepare(q{SELECT the, info FROM thetable WHERE the = 'R'
>> FOR UPDATE });
>> Not a perl solution -- but you could add a column or a table that tracks
> which rows that you are currently processing.
Thanks Selena. I (actually the team) had thought of that but it seemed
so _not RDBMS_. :-)
Also if the script/process fails for some reason I'm thinking that the
DBI/DBD/database will handle it correctly. Incremental commits etc.
I'll try one of the Pg lists and probably Chapter 12 of the Pg manual
which discusses how FOR UPDATE(SHARE) and SELECT in general is handled.
Rod
--
>> Maybe I shouldn't admit this (don't hurt me, Randal!) - but I have a
> printing system for barcode printers that could get accessed by a
> variety of people at the same time. I change the status inside a
> transaction to reference the process ID (and the print logfiles have the
> PIDs in them). That way, when there's a failure, I can track link it to
> a specific file that was printed (all the files have the PID embedded in
> them). Also, if two jobs get called simultaneously, there's no
> double-printing.
>> This type of thing gets you out of the business of policing your cron jobs.
>> -selena
>>