Servlet 3.0 and Comet/long-polling: What happens during these specific scenarios?

I took a look at a brief overview of Servlet 3.0's implementation of server push here and left with more questions than I came in with. The questions are related to my use case: implementing a dynamic notification system amongst "friends", a la Facebook. Conceptually thinking about the problem, I would approach it as so:

1. Put an infinite jQuery loop in each page, containing code to issue an XMLHttpRequest "get" request to the server
2. Allow the server to store the request/response objects related to these type of XMLHttpRequests in an application-scoped map (with the help of AsyncContext and .startAsync()), keyed by the user's website ID
3. Whenever a user engages in an action that spawns notification, query the application-scoped map for IDs of the user's friends, and using the response objects stored there, send the notification to each friend.
4. Each of the friends receive the notification, and the infinite loop on the pages they're on issue XMLHttpRequests again (due to the infinite loop)

Assuming my system is conceptually sound (and if it isn't, please tell me what's wrong), there are a couple of issues that I see with this system:

1. What happens to a request/response pair in the map after the response is used? Am I supposed to manually delete it from the map, or wait for the loop on the client side to send another request so the stored request/response object pair can be replaced by the pair associated with the new XMLHttpRequest? The link above uses the words "开发者_如何转开发committed" and "uncommitted" in reference to response objects. Can someone explain what those words mean in this context (I have a feeling they're related to the longevity of the response objects)?

2. What happens if two or more of a user's friends engage in actions that cause notifications at exactly the same time? There is only one request/response pair stored per user. Whichever friend's action happens to find the user in question's request/response pair gets its notification sent to that user, but what about the actions from the other friends? If they all happen at the same time, then the other actions won't have a request/response pair to use to send a notification until the user sends another XMLHttpRequest to be stored in the map. Presumably other actions will parse the map and either find no entry for that user (because its been manually deleted after the other action used the response), or find a "stale" request/response object that has already been used. I'm assuming that a response object can't be used for two different responses, so how would somebody go about rectifying this?

3. What happens if a notification is sent to a user when the user is switching pages? If we view a fully loaded web page as an open window for receiving notification requests, and a loading one as a closed window (because it is unable to receive and process responses to the XMLHttpRequests sent by the previous page), the notifications sent during this time frame will be lost. Is there anything I can do short of querying the database for new actions and generating notifications that way on page load?

4. Finally, what happen when a user navigates away from the site and the session expires? Are we expected to periodically iterate through the map and delete requests associated with no existing sessions?

Sorry if this was a long read. Even if you can only answer one of the above questions it would help!

1. The response is kept until it times out probably. you keep pushing new info on it over and over again. That is what comet is. You don't loop get requests forever, you handle the data that is streaming from the server as it comes, 1 get request will last until it times out, then in the complete function issue another get.

2. Again, the response is still available, you are only writing on it, not closing it every time.

3. One way would be to timestamp all notifications and load the page with data from a certain time, your initial get request then provides the timestamp and you are then up to date.

4. I assume again, you hold it until it times out.

So just to better explain what is happening here,

• Your page is loaded and sends a get request.
• The request/response is stored in the map.
• Every update is then sent on the SAME request/response pair.
• Your get request listens for readystate === 3 (data received) and reads the data getting anything new that has been sent.
• When they timeout/have sent a certain amount of data/whatever they are removed.