0

I know how to do a session pattern without callbacks like here How to organize RMI Client-Server architecture. But i don't know how to do one with callbacks. Do I need another session object for the client to pass to the server when logging in? If yes where do i keep it in the server side: hold a reference of the client session in the server session, or a collection of all client sessions somewhere else like the login server? If no what is the object that implements the client callback methods?

Maybe someone can give a code example like in the question i linked, because that one was clear and I didn't find one for the callbacks.

The answer doesn't have to be strictly RMI but I saw a lot of questions on this with no answers so i added the tag.

Community
  • 1
  • 1
Mark
  • 2,167
  • 4
  • 32
  • 64
  • 1
    Thanks for the immediate downvote with no explanation on my first question on this site after I helped others myself here. very nice – Mark Sep 19 '16 at 06:08

1 Answers1

1

You need a remote object for the client to pass to the server, on which the callbacks are called. It's rather likely to be a session object given that you're supplying it on login, but there isn't really enough information here to be sure. It depends on what you want it to be.

If you want it to be a session object, i.e. one that is unique to the session and does not survive it, you should ensure:

  1. That the client unexports it when logging out, and
  2. That the server loses its reference to this object when logout occurs, which is easily done by storing it in the server-allocated session object.
user207421
  • 305,947
  • 44
  • 307
  • 483
  • OK I'm doing 1 and 2 already. I was confused by when you said "The session object also contains the callback of course." in another answer here http://stackoverflow.com/questions/35781694/how-to-properly-identify-and-hold-client-references-in-rmi-callback/35784285#comment66398832_35784285. i didn't understand if the server sessions object contains the client session or something like that because you said "also". what did you mean by that please? – Mark Sep 21 '16 at 18:17
  • That's exactly the same as what I said in this answer at (2). – user207421 Sep 22 '16 at 00:09
  • Ah OK yes. So is there any reason for the callback session to implements Unreferenced, or is the server session implementing it enough because the only reference to the client session is through it? second thing: now the server should keep a list/map of server session objects which it uses to get the client session objects if it wants to do something like send a message to all clients, is this right? – Mark Sep 22 '16 at 07:08
  • Either the callback object should implement `Unreferenced` or the client should unexport it specifically when it's done with the session. Your choice. The server doesn't need a list of session objects. Each client has its stub to its own session, it invokes remote methods on the session, the session does whatever it does and invokes the callback stored within it. I don't see any need for anything more. – user207421 Sep 22 '16 at 07:18
  • Sorry i still don't see how to do this situation then: 1 client sends a message to all other clients by invoking the method `distributeMessage` on the server session object. that server session object can invoke callback methods on that client because it holds a reference to its session object, but how does that server session object calls methods (`sendMessageToClient`) on all other client session objects? – Mark Sep 22 '16 at 07:25
  • Ah well if you're broadcasting you need a list of sessions, certainly. Not otherwise. – user207421 Sep 22 '16 at 07:47
  • So just to be clear, the list is of server session objects and i retrieve the client session object from each one? i don't need a list of client sessions directly, yes? – Mark Sep 22 '16 at 08:00
  • No, you can get them from the server-side session. No need to keep a dog and bark yourself. Or else keep *only* a client callback list, but surely a session list would be handier? – user207421 Sep 22 '16 at 08:01
  • you are right. the server session holds the client information, so why not hold the client session too. I'm using a map to hold the server sessions where the keys are identifiers so i can pull session on demand. unless you see see something wrong i'll call this part complete. Thank you a lot for the patience and help! – Mark Sep 22 '16 at 08:14
  • I don't think you should call the client callback a session, or session object. It's a callback, and it's per-client, but it isn't the session, or a session object. It is *coextensive* with the session, but the session is defined by the lifetime of the per-client session object at the server. – user207421 Sep 22 '16 at 08:23
  • Alright i'll accept the terminology correction. makes sense. – Mark Sep 22 '16 at 08:27