How and when is a JCO connection closed in version 3.xx?

[Former Member]

Hi, in older versions of JCO (2.xx), the connections where handled directly: the developer needed to create the connection and then close it. It was intuititve.

With the newer versions there's no closing connection method, just getDestination methods.

I was wondering: how and when is an established connection closed?

Thanks in advance.

[MarkusTolksdorf · Accepted solution]

Hi Fernando,

Connection management has been moved into the JCo runtime. Separation of concerns: Applications should concentrate on application logic and should not have to deal with technical stuff like opening and closing connections.

When a connection is closed depends on the configuration of the destination, from which the connection was generated from. Typically, connections are pooled and as long s the idle timeout is not reached, the connection will remain open. How long and how many connections are pooled is described in the configuration of a destination. Check out the DestinationDataProvider documentation. Furthermore, connections stay open that are still in use in an active client session context.

Best regards,

Markus

[Former Member · Accepted solution]

Perfect. But if i open a context, the connection will last until i close (end) that context, right?

[MarkusTolksdorf · Accepted solution]

Yes, that's correct. But only if the session to which the context belongs is still alive. Otherwise, it will be released and returned to the pool.

Best regards,

Markus

[Former Member · Accepted solution]

Thanks Markus, i'm new to JCO and full of doubts. You've been incredibly helpful.

This is what i have in mind:

I'm doing a web Project in which i need to connect to SAP. This is being done currently via web services but is too slow. If i use a JCO connection and keep the context open, i can speed everything up by having stuff in my RFC already 'wired'.

This will only work if i keep the context open.

My doubt is if this can be done: having a single JCO with a context open for every client of my web App? (without fear of this connection being released and leaving my web App clients without communication to SAP)

[MarkusTolksdorf · Accepted solution]

Hi Fernando,

what do you mean with a single JCo? Actually, you only need to start a context, in case you need to keep backend state. The connection will remain open even without using a context, that's the sense of pooling. I would recommend to restrict contexts to use cases, in which you really need them. How many concurrrent connections are possible depends on the backend, how much it can stand and how many connections you allow on client side.

Best regards,

Markus

[Former Member · Accepted solution]

Markus, how are you?

I'm facing the following problem:

> My idea is to have a connection pool to a SAP backend. Initially I intended that every connection to SAP had it's context open. This way everytime i handed one of this connectio, the context in the backend was opened and i could take advantage of this to optimize response time.

The problem i'm facing is that once I get a connection(destination) and open it's context, it's never returned to the pool. I guess JCO library sees them as active (because of the unended context).

Is there a way to get around this to take advantage of opened context? Or is the only choice i have handing a direct (unpooled) connection to every client (with it's openned)

Thanks in advance Markus.

[MarkusTolksdorf · Accepted solution]

Hi Fernando,

In case you don't call JCoContext.end(destination) within the session scope, the connection will only be returned to the pool if the active SessionReferenceProvider inidcates the surrounding session as inactive, otherwise the connection is considered busy and is not returned. Simply do not start a context to avoid this, if you don't need a context. Are you executing several calls after wach other that rely on some backend state introduced by a previous one? If the answer is no, don't use a context and the connection will be returned to the pool. There won't be the need to open a new connection as long as a successor call is happening before the idle timeout closes the connection.

Performance difference is small compared to stateful with JCoContext.begin(destination), but it saves a lot of resources by only opening as many connections as really needed.

Best regards,

Markus

[MarkusTolksdorf · Accepted solution]

Hi Fernando,

just saw in your other question that you need statefulness as you obviously load some data in the backend to ABAP context - at least this is my understanding from your remark there. In this case stateless sequences won't fit.

Best regards,

Markus