Archived
This forum has been archived. Please start a new discussion on GitHub.
Storing Proxies with Freeze and moving the database
in Help Center
I am using Freeze to store state of persistent classes in an icebox "server" application. These classes include proxies to other classes which are also in the freeze database.
My trouble comes with moving the database from the development machine to the production environment, and I think if I use IcePatch2 to replicate the database to a backup server I will have this issue as well. In my config.service file I configure the object adapter to MyAdapter.Endpoints=tcp -p 10000. I test the service on my development machine in one window and debug the client app in another window.
However, now I want to move the service and database to the production machine and when I point the client endpoint to the production server, I connect just fine, but if the client instantiates a stored class which contains a proxy to another object and then that second proxy is used, I am unable to instantiate the second proxy object. Turning on tracing (or just using dumpdb) I see that the second proxy was stored with and endpoint of the form: <category>/<id> -t:tcp -h <ip address of dev machine> -p 10000.
My proxies stored in the Freeze db can now only be restored if the service is run on the dev machine. How do I best fix this? In case it matters, both the server application and the client applications need to be able to instantiate the saved proxies.
My trouble comes with moving the database from the development machine to the production environment, and I think if I use IcePatch2 to replicate the database to a backup server I will have this issue as well. In my config.service file I configure the object adapter to MyAdapter.Endpoints=tcp -p 10000. I test the service on my development machine in one window and debug the client app in another window.
However, now I want to move the service and database to the production machine and when I point the client endpoint to the production server, I connect just fine, but if the client instantiates a stored class which contains a proxy to another object and then that second proxy is used, I am unable to instantiate the second proxy object. Turning on tracing (or just using dumpdb) I see that the second proxy was stored with and endpoint of the form: <category>/<id> -t:tcp -h <ip address of dev machine> -p 10000.
My proxies stored in the Freeze db can now only be restored if the service is run on the dev machine. How do I best fix this? In case it matters, both the server application and the client applications need to be able to instantiate the saved proxies.
0
Comments
-
Hi Brian,
This is the danger of storing "direct" proxies in a database. You can avoid this by storing indirect proxies instead, in conjunction with a location service such as IceGrid. Another option would be to use a symbolic hostname that you could safely use in your persistent proxies that gets mapped to the appropriate development or production addresses via DNS.
If you're looking for a way to modify your database to use the production hostname, you can either write a small Freeze program to perform this migration, or you can use FreezeScript. FreezeScript provides string manipulation functions, as well as proxy/string conversion functions, that should allow you to update the persistent proxies.
Hope that helps,
Mark0 -
Thanks for the quick reply. I will go read up on indirect proxies...0
-
If I use indirect proxies, such as MyObject@MyAdapter, for proxy resolution in code running in the application which hosts MyAdapter, will there still require an indirect lookup? or does Ice know that an adapter by the name "MyAdpater" already exists local to the calling application.0
-
Hi,
Ice always checks locally first when trying to resolve an indirect proxy, so Ice will not query the locator if the proxy refers to a local object adapter.
Regards,
Mark0
