Proper disposal of IInfoStore?

[atul_chowdhury2]

Hi folks -

I'm hoping that one of the BOESDK platform technical experts can provide us with some best-practice guidance around IInfoStore management.

My server application works 24x7 and periodically (every minute, for example) creates IInfoStore instance. How do I properly release resources used by IInfoStore instance? Should I do something special like close/dispose or can I just leave it for GC?

Thanks in advance -

Atul

[Former Member · Accepted solution]

Hi Atul,

The IInfoStore interface acts as a controller, or gateway, to InfoObjects in the CMS. The IInfoStore interface is used to communicate messages between your application and the CMS to create, retrieve, and commit (through an IInfoObjects collection) all instances of IInfoObject that are stored in the CMS repository.
To create a connection to the InfoStore service, you must log on to a valid session (com.crystaldecisions.sdk.framework.IEnterpriseSession).
Once you have established a connection to the InfoStore service, you can use the methods of the IInfoStore interface, such as query, commit, and schedule, to communicate with the CMS.

To ensure that the maximum number of licenses is available, always log off any users who no longer require a session. Each active session requires a license. When the maximum number of available licenses is exceeded, additional users will be unable to log on to the BI platform.
Additionally, it is beneficial to destroy all variables that are stored in the session and release resources on the server. Use the Invalidate method which destroys all variables in the application server's session object including the IInfoStore object.

Hence if you log off/invalidate the user session, it will implicitly dispose IInfoStore instance as well.

Hope it helps.

Regards,

Anchal

[atul_chowdhury2 · Accepted solution]

Thanks Anchal - this is helpful. I was still wondering about using the *same* IInfoStore from a *single* session across multiple threads and whether that's thread safe, expeiments so far tell me it's OK but if someone can further confirm, all the better.

[Former Member · Accepted solution]

Hi Atul,

You can refer to the SAP Note "1700099 - Does Business Objects SDK Object Model support multithreading ?" here. For your refernce, below is the content of the SAP Note:

========SAP Note :1700099======

First, we must define strong and weak thread safety:

Strong thread safety: mean that any object instance of a given class is usable simultaneously from multiple threads, including using mutable operations.

Weak thread safety: is the normal thread safety you get for objects when you design them without static shared state, or you take care to lock this state. It is also the type of thread safety that applies to non-member functions (they can be called by any number of threads, as long as all the arguments are either not shared or passed by value) as long as you don't access any global state in a thread-unsafe way. This kind of thread safety generally allows simultaneous reading of the same object instance on multiple threads, and allows the simultaneous reading and writing of distinct object instances on multiple threads, but doesn't allow simultaneous writing or reading and writing of the same object on multiple threads without locking.

Note:Even less thread unsafe objects potentially cannot even be read across multiple threads, or potentially even have issues with using district objects across threads without additional synchronization.

Generally, BusinessObjects SDK classes and functions  obey weak thread safety.  There are exceptions, however.  For example, different InfoObjects which originated from the same session cannot necessary be used in a thread-safe way on separate threads, because each object has a hidden reference to originating session, which isn't thread safe. So even though you don't think you are doing any cross-thread sharing, the implementation may be doing it for you.

Conclusion: you can use multithreading if :

1. You keep in mind the points made above, 
2. Do not exceed the maximum on-demand processing load of your BusinessObjects environment. 
3. However, we generally encourage the use of the Business Objects scheduling capabilities, since multiple reports can be scheduled within a single InfoStore schedule request; which is our defined way of batch processing reports.

Hope it helps.

Regards

Anchal

[atul_chowdhury2 · Accepted solution]

Thanks, Anchal for the thorough response on this.

Marking comment as answered.