Archived

This forum has been archived. Please start a new discussion on GitHub.

threading and proxy question

Hi,

If I have 1 object, and I add to an objectadapter... How is it used with threading in mind?
* Are all the incoming requests streamlined to this one object, or should I make it a factory which generates child objects where the user can work on?
* Or is this one object used multithreaded, so I only need one, and no serialisation of requests [probably wrong answer this one].

Probably it's the first answer, but then my question arises what to do with all the proxies you created through the factory? How can I determine that a proxy is not needed anymore (I can't trust the clients ofcourse as of networking/coding issues)? I already took a look at the session sample which seems a good place to start.
But specifically I have a question what if in the session, there are created a LOT of proxies. How can I determine which I can remove? As I don't want thousands of proxies to clutter my server. I can ofcourse put in my slice definition a method close() or destroy() or so. But then I hope the client part will always be nice and destroy the proxy when they don't need it anymore... And in this case I can't thrust the client to refresh() at a certain time and so on... Is there any to counter this?

Short:
1/ I have a session-factory -> creates sessions for everyone who wants (proxy). [sessions can time out]
2/ Those sessions provide multiple DataRows (also proxies).
Question:
3/ How (and when) can I know when to remove those proxies? [1 way is at session destruction, but is there a sooner way without client interaction?].


Thanks,
Steven

Comments

  • matthew
    matthew NL, Canada
    If you have multiple threads in the server-side thread pool and multiple concurrent requests for the same object then they will be dispatched concurrently. Whether your servant is concurrent depends on its implementation (ie: does it do the correct synchronization).

    With respect to your factory question I suggest reading the numerous articles in the connections newsletter that discuss this. The short answer is that in presence of badly behaved clients then a timeout is the best way to determine that the session is no longer used.
  • Question 1: that's what I expected the behaviour to be...
    Question 2: that's also what I expected, but not what I like to hear ;)

    Thanks for the support matthew!