Ice Client Connection , how to save on round trips ?

In order to create an ICE connection we do the following -
ic = Ice::initialize();
string proxydtls="ICEServer:default -h "+(Conf::getConf()).getStrValue("ICEServer") + " -p " + (Conf::getConf()).getStrValue("DBCONNPORT");
base = ic->stringToProxy(proxydtls);
defaultProxy = dbtxn::dbDefPrx::checkedCast(base); // trip 1 - default proxy
dbdts = dbtxn::dbDTSPrx::checkedCast(dbdefprx, "ICEDates"); // trip 2- Specific Facet

We need to know which is the server round trip . trip 1 or trip2 . We would need to know this in order to save on server round trips.

Thanks n Regards .

stringToProxy is a local operation, so there is no round trip.

The two checked casts each incur a round trip. If you do not need to use
defaultProxy later in the code, or if you are certain that defaultProxy will have the expected type, you can replace the checkedCast with an uncheckedCast, in which case the Ice run time simply will take your word for it.

In fact, you can use an uncheckedCast any time you like and avoid the cost of the round trip. But, of course, in that case you had better be right; otherwise, if the type or facet are not correct, you will encounter run-time error later, when you use the proxy.

Are you certain that avoiding the round trip is actually necessary? If the application does any significant amount of work with these proxies, the extra RPC will be unnoticeable. So, unless you have profiling data to show that the round trips really are a significant source of overhead, trying to avoid the round trip is likely a premature optimization.

Cheers,

Michi.

Hi,

Thanks a lot for ur help Michi . I guess this will help me design my pooling methodology better .

Regards ...
Faiz

Hi ,

What we are thinking is not to destroy the proxies and let them be alive. Will a single proxy suffice in case it is a multi threaded environment ?

Please let us know .
Thanks and regards
Faiz

Hi,

Yes, proxies are thread safe.

Cheers,
Benoit.

Yes, even a single proxy will keep the connection open. You can set Ice.Trace.Network to monitor how connections are opened and closed, if you want to experiment.

Cheers,

Michi.

Super ...
Off we go guys .. will sure keep you all posted .

I wrote a pretty in-depth article on this topic in issue 24 of Connections. See http://www.zeroc.com/newsletter/issue24.pdf for details.

What we are thinking is not to destroy the proxies and let them be alive.

As I explain in the article, the life cycle of connections and the life cycle of proxies that use the connections are independent. In particular, the destruction of the last proxy that uses a connection does not destroy the connection. Please see the article for full details on how the Ice run-time manages its connection pool. If you have further questions please ask!