How to access the HTTP Request or Session object in Service implementation?

[former_member244596]

Hi all,

In typical RESTful web applications it is possible to access the HTTP Request object, the HTTP Session object etc. Typically you use them in your service implementation. Just to give you an example: with Jersey (a common REST lib for Java) you can simply inject the Http Servlet Object with @Context HttpServletRequest. There are many reasons why you might need to access the request object, but also the response object etc (but that's ouf of scope for this discussion).

I am currently trying to find more about handling of concurrent access. The following gives you a good idea of how to apply ETags in your Gateway application: http://scn.sap.com/thread/3298520

What we actually want is to migrate our SessionID based locking mechanism from an old BSP application to our new Gateway services. The problem is now that there is no way to access the Http Request or Htp Session in the service implementation, is that correct? We need a real locking mechanism, ETags are not enough. In other words: we need pessimistic locking!

My idea for solving this would be creating a Lock entity, a corresponding Locks entity set + service implementation. The Lock entity would contain fields like sessionId, userId, lockTimeStamp, lockedObjectId, entityName etc. Before editing an Entity the client application (in our case a simple SAPUI5 application) would have to create a Lock for any given entity first and when pressing the save button the Lock would be deleted (Lock creation + deletion via Gateway services for the Lock entity mentioned above). When creating a Lock the SAPUI5 application has to retrieve the current sessionID from the cookie and pass it to the create service.

1.  What do you think?

2.  Are there any best practices for pessimistic locking of Gateway entities?

3.  Wouldn't it be a good idea to have the possibility to access the Http Request etc. inside the service implementation, especially for the UPDATE service implementation (feature request)?

Cheers,

Nabi

[Former Member · Accepted solution]

Hi Nabi,

Gateway is stateless so you cannot maintain a pessimistic lock without breaking your chosen architecture. If you want pessimistic locking, why use a stateless framework?

How do you deal with locks that were placed and never released due to client disconnection, unacceptable session time, etc?

So my response is

1.  What do you think? Bad idea.

2.  Are there any best practices for pessimistic locking of Gateway entities? No because it is bad practice.

3.  Wouldn't it be a good idea to have the possibility to access the Http Request etc. inside the service implementation, especially for the UPDATE service implementation (feature request)?

Not if people want to use it for idiosyncratic pessimistic locking As far as the http request is concerned, you can read request headers them but that is about as far as it goes. I've tried to access the request myself in the past but came to the realisation that in the majority of cases where this might be needed, the result is subversion of the REST architecture and not something to be pursued. Gateway still needs some additional features but I don't think this is one of them.

SAPUI5 is not constrained to "Gateway only" in terms of data model so you might want to look at a different data provider, where pessimistic locking is acceptable.

Regards

Ron.

[former_member244596 · Accepted solution]

Hi Ron,

Well, actually I do not want to use pessimistic locking if you ask me. I absolutely understand your points and I agree to most of them. Let me tell you a little where the requirement actually comes from:

In typical SAPGUI applications you often have locks to make sure that a second user is not able to edit an object that is currently being edited by someone else. You even have typical SAP web applications that use locks the same way. In other words: a user cannot change a given object while someone else is editing it. As you can see pessimistic locking is not uncommon even for HTTP (which is stateless itself), although I do not always like it in web applications (for some of the reasons you mentioned above). Now we have a web application and we need to keep the pessimistic locking behavior

Pessimistic locking has both advantages and disadvantages. You have only mentioned the disadvantages:

- If you want pessimistic locking, why use a stateless framework? HTTP itself is stateless, does that mean I am not allowed to use pessimistic locks? I let the requirements decide...

- How do you deal with locks that were placed and never released due to client disconnection, unacceptable session time, etc? Good point and I thought about that as well. We would use common strategies for releasing locks automatically. We are not re-inventing the wheel here, this is absolutely nothing new.

Maybe it is a bad idea to use pessimistic locks, but I prefer to let the business requirements decide. Just because the Gateway does not support pessimistic locks out of the box it doesn't mean it's a bad practice or you should never use it. However, I understand that there are many examples where you do not need or should not use pessimistic locks.

Now think of the following Use Case:

User A wants to change an entity and by changing its attributes. Now let's assume this takes 30 minutes and the user does not save in between. Now User B starts changing the same entity at the same time but presses the save button only after one minute. 29 minutes later User A presses the save button and receives an error because the entity has been changed in the meanwhile (different ETag). Now, if there is no (maybe error prone) automatic "merging" possible then User A might have to re-do the work again. Now also assume that preventing issues like these is a major requirement in your project. In that case optimistic locking might not be a good choice. Pessimistic would help here maybe better (with the disadvantages you mentioned and some more, i.e. all others would have to wait...). How would you solve this with optimistic locks?

How did you read the HTTP Headers in your service implementation? I did not find the right APIs for that... Accessing and changing the HTTP Headers in RESTful services is very common, both Request and Response headers. But I do not want to open a new discussion...

Cheers,

Nabi

[kammaje_cis · Accepted solution]

Hi Nabi,

Loved reading your post. I am at a client location and requirements for pessimistic locking are always there and it makes perfect sense. The advantages of pessimistic locking cannot be ignored at all.  As you said other SAP technologies using http have pessimistic locking as well.

I had thought about a similar solution and half way in implementing it. But just to lock and unlock, sending a http payload with all the headers might be too heavy. So I am also exploring Websockets currently. You can see my approach in the comment section of this well written blog on websocket.

Let me know your experiences in this exciting journey.

Thanks

Krishna

[kammaje_cis]

Yes, As I understand you cannot get http request or http session at data provider class. But if you want the http request headers use below code inside your  *DPC class. But this would not work in *DPC_EXT class since mo_facade is private .

     DATA: lt_client_headers       TYPE tihttpnvp,

    lt_client_headers = mo_facade->get_request_header( ).

[Jitendra_Kansal]

You can close this thread if your query has been answered.

Rgrds,

Jitendra