Hi Daniel, Maybe make procedural wrappers around all events undertaken and simulate it?
ie: 1. Client connects to MS SQL Server (Application Server) and PG Server 2. SQL Server connects to PG Server aswell 3. Client begins new record process 4. New record process starts by putting PG into serializable transactions (so App Server can respect the changes). 5. If one server transaction fails roll back the other and vice versa and start again. 6. If all good, commit both at the client as the last item in the new record process. Meanwhile the Application Server may make it's own calls against Pg through strored procedures. If any part of this PG transaction fails, error comes back to App Server and App Server transaction roll backs, which tells the client and the client rolls back it's own call to PG. I don't know if this is a viable method (v. messy) and given the concurrent update issue this may play havoc with the client logic if both the client and the app server attempt to modify the same data at the PG Server. Can all connections simply go through the App Server leaving it to manage the PG stuff in it's own transactions (still, concurrent update problem can occur if dealing with same records)? Rgds, Jason On Thu, 17 Jul 2003 09:45 pm, Daniel Schuchardt wrote: > Hi @ all, > > Our software consists of a Client-Side App and a Application Server. > Every client owns a direct connection to the PSql-Server and for every > Client the Application-Server also creates a connection to the > PSql-Server. The problem is that it is nescesary that the Client and the > Application-Server are in the same transaction. But how say connection x > to be in the same transaction like connection y? > > Thanks for help, > > Daniel ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
