Re: .NET Remoting
From: Paul Glavich (glav_at_aspalliance.com-NOSPAM)
Date: 02/09/04
- Next message: Ice: "Re: dcom vs com+ vs remoting"
- Previous message: Ivan Farkas: "Old (1.0.9.0) Microsoft.Samples.Security.SSPI version on MSDN"
- In reply to: Softwaremaker: "Re: .NET Remoting"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 9 Feb 2004 22:24:59 +1100
Sorry for the late reply but.....
In the case of remoting, the Trx boundary is the physical machine. So a
"client" machine starts a trx, then remotes to "server" machine. The trx
boundary for the client is that clients physical machine. If the "server"
starts a trx, its boundary is its own physical machine (assumnig you are not
using COM+ and DCOM to span machines and similar methods). In ADO.NEt you
can start a Db trx from a machine, which goes to the DB machine and performs
the transacted operations so it technically spans a machine boundary but its
also not remoting.
Hope thats clear. Basically, remoting means trx boundary is limited to that
physical machine.
-- - Paul Glavich "Softwaremaker" <msdn@removethis.softwaremaker.net> wrote in message news:OvGEskT6DHA.2748@TK2MSFTNGP09.phx.gbl... > Hi Paul, > > OK. Point duly noted. > > Thank you very much for the tip. I appreciate it lots. > > One other question, > <Quote> > ...any remoted calls would only require the trx boundary on the remote > machine and not the "client". > </Quote> > > In the above quotes, what are the differences between trx boundary on the > remote machine compared to the "client" in terms of design. In other words, > how do you define trx boundary on the client and remote machine. > > Thank you so much > > ++++++++++++++++++++++++++++++++++++++++ > > "Paul Glavich" <glav@aspalliance.com-NOSPAM> wrote in message > news:u43D3RL6DHA.3360@tk2msftngp13.phx.gbl... > > When using remoting to access an object on another physical server, it is > > like a regular anonymous request, in that security context and > transactional > > context *begins* at this new request. You can use Integrated security to > > authenticate but there is no caller context automatically propagated with > > the call (like DCOM) and similarly, if you start a trx on server 1, then > use > > remoting to go to server 2, the trx context is lost and not carried to > > server2. So the trx boundary would be limited to server 2 in this case > > (assuming it does not use remoting to access another server). > > > > This basically means you need to cater for this limitation in your design > so > > that any remoted calls would only require the trx boundary on the remote > > machine and not the "client". If this limitation is not something you can > > live with, you could always use DCOM to access your remote components so > > that caller context/security context and trx integrity. > > > > -- > > - Paul Glavich > > > > > > "Softwaremaker" <msdn@removethis.softwaremaker.net> wrote in message > > news:uRtByVJ6DHA.2168@TK2MSFTNGP12.phx.gbl... > > > <Quote> > > > In .NET Remoting,...However, calling a component through remoting does > not > > > maintain transactional integrity and security context > > > </Quote> > > > > > > Dear fellows, > > > > > > Was wondering if anyone care to shed some light on the above sentence, > esp > > > the part on .NET Remoting Component not maintaining transactional > > integrity > > > and security context ??? > > > > > > Thank you. > > > > > > > > > > > > >
- Next message: Ice: "Re: dcom vs com+ vs remoting"
- Previous message: Ivan Farkas: "Old (1.0.9.0) Microsoft.Samples.Security.SSPI version on MSDN"
- In reply to: Softwaremaker: "Re: .NET Remoting"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|