Maintaining a transaction across multiple HTTP requests

--_9BF71BCA-A4D6-4170-A3EF-7600D1DECEC4_
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all,

I need to write a server script that will be used to synchronise a SQL Serv=
er CE database on a Pocket PC with a central PostgreSQL database. Ideally, =
what I'd like to do is pass modifications made on the PPC to the script whi=
ch then begins a transaction (thus ensuring no futher data changes will be =
seen by the client) and checks for any conflicts with changes made on Postg=
reSQL since the last synchronisation. If there are any, the script will ret=
urn details to the client for conflict resolution. When the planned conflic=
t resolution is returned by the client, the required updates are executed w=
ithin the original transaction which is then committed.

The difficulty with this plan is that the transaction must be maintained ac=
ross 2 or more individual http requests (which may normally be serviced by =
different Apache child processes of course, thus preventing storage of a co=
nnection handle in a session variable). Is there conceivable way I can achi=
eve this, or should I go back to the drawing board?

Regards, Dave.

--_9BF71BCA-A4D6-4170-A3EF-7600D1DECEC4_
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML dir=3Dltr><HEAD></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#000000 size=3D2>Hi all,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I need to write a server script that will =
be used to synchronise a SQL Server CE database on a Pocket PC with a centr=
al PostgreSQL database. Ideally, what I'd like to do is pass modifications =
made on the PPC to the script which then begins a transaction (thus ensurin=
g no futher data changes will be seen by the client) and checks for any con=
flicts with changes made on PostgreSQL since the last synchronisation. If t=
here are any, the script will return details to the client for conflict res=
olution. When the planned conflict resolution is returned by the client, th=
e required updates are executed within the original transaction which is th=
en committed.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The difficulty with this plan is that the =
transaction must be maintained across 2 or more individual http requests (w=
hich may normally be serviced by different Apache child processes of course=
, thus preventing storage of a connection handle in a session variable). Is=
there conceivable way I can achieve this, or should I go back to the =
drawing board?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Regards, Dave.</FONT></DIV></BODY></HTML>

--_9BF71BCA-A4D6-4170-A3EF-7600D1DECEC4_--
Dave Page [ Do, 03 Juni 2004 20:46 ] [ ID #141830 ]

Re: Maintaining a transaction across multiple HTTP requests

> -----Original Message-----
> From: Jack - [mailto:jackhappy6 [at] hotmail.com]
> Sent: Fri 6/18/2004 5:08 PM
> To: Dave Page
> Subject: Maintaining a transaction across multiple HTTP requests
>
> could u store of a connection handle in a session variable - but on the=

> server side have the session information stored on a shared database =

> instead of a file?

Hi Jack,

I considered that approach, but the problem is that the handle is only vali=
d for the apache process that it was opened under. If the second request is=
processed by a different apache process, then it'll all go horribly wrong =
:-(

Regards, Dave

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo [at] postgresql.org)
Dave Page [ Fr, 18 Juni 2004 18:37 ] [ ID #141865 ]

Determining transaction status

Hey guys,

Is there any way to determine transaction status without using
pg_transaction_status() (which hasn't been officially released yet)?

I'm using PostgreSQL 8.0.2/PHP 5.0.4.

Thanks!

--
Aaron Dummer
aaron [at] dummer.info


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq
Aaron Dummer [ Mo, 02 Mai 2005 18:34 ] [ ID #773741 ]

Re: Determining transaction status

Hi,

On 5/2/05, Aaron Dummer <aaron [at] dummer.info> wrote:
> Is there any way to determine transaction status without using
> pg_transaction_status() (which hasn't been officially released yet)?

You can patch your ext/pgsql/pgsql.c from CVS. pg_transaction_status()
is added in revision 1.315.
[http://cvs.php.net/php-src/ext/pgsql/pgsql.c]

Regards.

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Volkan YAZICI [ Mo, 02 Mai 2005 19:06 ] [ ID #773742 ]

Re: Determining transaction status

> Is there any way to determine transaction status without using
> pg_transaction_status() (which hasn't been officially released yet)?

No.

Chris

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org
Christopher Kings-Lyn [ Di, 03 Mai 2005 03:22 ] [ ID #775588 ]
Datenbanken » gmane.comp.db.postgresql.php » Maintaining a transaction across multiple HTTP requests

Vorheriges Thema: last value
Nächstes Thema: Can't compile plphp