[openorb-users] ServantLocator/data storage/multi-threading (long)

[Martin W. <ma...@cy...>]

Dear openORB Users-

I am using openORB to develop an application that uses CORBA as middle-wear to interface between the end-user and a database.
Despite posts to comp.object.corba and comp.lang.java.corba I am stuck and am hoping someone here can help me out.

In my project there is a POA that contains objects that represent data stored in the database. The POA is set up to use a ServantLocator to return servants for method invocations. To conserve resources I want to use the evictor pattern as described in "Advanced CORBA Programming with C++" (ACPwC++).
I would like to keep a certain maximum number of servants instantiated at any one point. If a request arrives for an object for which there is no servant instantiated I want to evict the least-recently used servant and instantiated a new servant for the object for which a request arrived.
The POA is set up to use the ORB_CTRL_METHOD.

Here are the problems I am having and the possible solutions I have so far. Please keep in mind that I do not know the internals of openORB and how it processes threads. I may be totally off with some of these:

-Requests and their processing can happen simultaneously since the ORB is multi-threaded. I need some way of knowing whether the servant is executing a request. A reference-count variable in the servant that is accessed in a thread-safe manner seems to be easy enough to implement: increment it in preinvoke and decrement it in postinvoke.

-If a request arrives for an object for which no servant exists I need to instantiated a new servant. If the maximum number of servants are already instantiated I need to choose one for eviction.
What if all servants are still showing a positive reference-count, i.e. are all still servicing long-running requests?
The way ACPwC++ seems to want to deal with it (translated to Java) is to remove all references to the servant to let it be garbage-collected. However:

-Any servant that is being evicted has to save its state to the database. I am not using the PersitentStateService but am doing everything by hand.
If I evict a servant by simply releasing all references to it, finalize will eventually be called on the Java object. This procedure could then save the state to the database. Big problem, though: what if -in the meantime- another request arrives to the POA for the same object. The ServantLocator has already released the old servant (even though it is still in memory since its finalize method has not been called yet) and thinks it needs to instantiate a new servant. The new servant queries the database for the current values. Since the finalize method has not been called on the old servant yet the data retrieved from the database is stale and outdated.

-If I want to save the servant's state to the database on eviction itself (i.e. within the ServantLocator's preinvoke operation) I can only pick servants that have a 0 reference-count (i.e. are not being used anymore).
If all servants are still being used and if I am at the maximum number of servants I want to have instantiated, my hands are tied: I cannot evict any servant but can also not create a new one!
What do people do in this situation? Should I make preinvoke wait? If yes, what is the best way of doing so?


I hope that someone can give me a hand with this. I cannot be the only one doing this sort of thing but all of my searches so far have turned up nothing.

Thank you for reading my email and for any and all help!
Sincerely-

	Martin Wehner


-------------------------------------------
Martin Wehner (KG6KLF)

e-mail: <ma...@cy...>
web:    http://www.cyclotomic.com/~martin
-------------------------------------------