How to enable/disable pooling while saving in DB?

[sreramb (Sreram)]

We had written a rest api to read and write business objects from a table - which does work fine.
Now, when we try to map one field of a Business Object (main table) as foreign key to dependent table and key in data in the dependent table, we do get Warning in logs like ‘Unable to borrow a pooled object, providing a non pooled object’ and we are unable to save values in the dependent table.
Is it possible to shed some light on what are pooled and unpooled objects and how to enable / disable pooling in API while saving values to DB?

Thanks,
Sreram

[david (David AZOULAY)]

@sreramb

We had written a rest api to read and write business objects from a table

What did you write exactly ? In Simplicité you don’t need to write code to get an API on a business object… Except if you are speaking about API naming mapping ? Can you provide example of what you are speaking of ?

Your question on foreign keys is also a bit confusing because establihsing links between business objects (and retreiving fields from the links) is something very basic in Simplicité. Maybe we are again speaking of API naming mapping here ?

@sreramb

Is it possible to shed some light on what are pooled and unpooled objects and how to enable / disable pooling in API while saving values to DB?

I don’t see any reason to disable object pooling during updates, why would you want to do that ?

The principle of object pooling is to provide a pool for business object instances in order to improve performances otherwise you are obliged to take care of business object instances lifecycle and synchronization. I don’t see the point of re-implenting specifically what the pooling is made for.

[sreramb (Sreram)]

We, basically, are trying to experiment what are the different methods by which we can create APIs in Simplicite. And more specifically if we ought to create multiple Business objects - one related to other with a common property, how do we do that ?

Were interested to delve deeper into pooling, as we started receiving ‘Unable to borrow a pooled object, providing a non pooled object’ warning on the Custom API we did implement & dependent BO was not saved. I do understand pooling was created with reusability and modularity in mind, but when I did go through the documentation for Simplicite regarding pooling, it said, non-pooled object will be returned if pooled objects are not available.

RESTServiceExternalObject

By which I became a bit more curious on this option.

And also, if we need to basically add some environment variables for the API, System parameters are the only option. ? What should we do for certificate files and secrets ?

Information on where the https://vamsi.renault2.simplicite.io/ instance is deployed will also be helpful.

Sreram

Sreram

[david (David AZOULAY)]

To ease management thank you to deal with only 1 topic per post (please post a separate post for you question on system parameters vs env variables and another one for details about hosting of your dev instances)

Business object API pooling is a standard mecanism that is used on the API enpoint when the system parameter USE_WEBSERVICES_OBJECTPOOL is set to yes.

By default it is set to no except for the non-authenticated public pseudo-user (which is the right configuration in most usual cases):

If you are using a technical authenticated user, you should also set it to yes for him.

Other pool-related parameters allow you to do some fine tuning on the pool sizes:

These parameters can also be overriden on a per-user basis.

There is no reason not to use object pooling for APIs, especially if there are many concurrent calls, because it is what ensures good performances and isolation.

When using the standard business objects APIs or the mapped APIs, the polled objects are used by default.

If you implement a custom API (again, you only have to do this for very particular cases, not for basic CRUD on your business objects) you MUST ABSOLUTELY use the borrow/return pattern on your business objects in your code => it will use the pooled instances if enabled for the user calling the API or temporary isolated object instances if not (but this will have a significant impact on performances):

ObjectDB obj = null;
try {
     // Borrow an API object instance from the pool
    // (ZZZ this instance MUST be returned to the pool, see below)
    obj = borrowAPIObject("MyObject");

    // Do something with obj...
} catch (Exception e) {
	// Handle exception
} finally {
    // Return the API object instance to the pool
    // (ZZZ this MUST be done in the finally block)
    if (obj != null) returnAPIObject(obj);
}

Writing it any differently might cause tricky concurrent/synchronization/lifecycle/… issues and poor performances/memory leaks/etc. => NEVER useGrant.getObject() or Grant.getTmpObject() in a custom API code (unless you know exacly why you are doing it, but I don’t see why it would be a relevant thing to do)

Note : This pattern is the one given in the examples of the documentation