Robert Treat wrote:
> On Monday 06 November 2006 20:24, Chris wrote:
>
>> Herbie McDuck wrote:
>>
>>> Alan Hodgson wrote:
>>>
>>>> On Thursday 26 October 2006 11:11, Amal burman <amalburman@yahoo.com>
>>>>
>>>> wrote:
>>>>
>>>>> postgresql database for this project. Here script one
>>>>> (booking.php) tries to setup a lock for update and ask
>>>>> user to fill-up the form. Now when the user fill-up
>>>>> the form and submit it for update, second script
>>>>> (update.php) update the database and releasing the
>>>>> locks.
>>>>>
>>>> You can't do this kind of thing in PHP. PHP resets the database
>>>> connection between scripts. The script is finished as soon as the
>>>> page is delivered to the client.
>>>>
>>>> Also, web connections are stateless and there is no way to even know
>>>> what web server process or database connection you'll be getting on
>>>> subsequent page views.
>>>>
>>> So is PHP and 'ANY' database a useless adventure when it goes to
>>> developing a robust business and accounting package?
>>>
>> No, it applies to anything you do in a web browser.
>>
>> The HTTP protocol is "stateless" which means all resources, connections
>> etc are killed at the end of the script. Resources of any type are not
>> kept alive at the end of a script.
>>
>> It's not a php thing or <insert random language here>, it's a HTTP
>> protocol thing.
>>
>
> In theory you can use prepared transactions to get around this, but I've never
> seen anyone fully implement it in PHP.
>
>
How exactly would that work? With PDO Prepare/Execute? Would you prepare
a transaction, and then store the PDOStatement object as a session var?
Or do you mean this is something that would have to be implemented in
PHP internals?
