DI-API and multi threading

[Former Member]

What are the implications of DI-API being single threaded?

Say you have 10 open DI-API connections in a pool:

1. Can you use them from different threads at the same time?

2. Can a connection be used from a different thread then the one it was opened in?

[Former Member]

I know this is a very old post, but did you manage to handle multiple connections to the same db with a connection pool without any memory problems?

i tried the same: created a connection pool that contains 4 connections to the same db but 4 differend company objects. then each single thread takes one of the connections and when it's done, it returns the connection to the pool. but after some random times i get a acception_access_violation.

[Gianluigi]

Actually Erez's comment is very much correct: DI API is about not messing with

the DB. And this is not a limitation but a very precise design choice - that BTW it

is a pretty standard one.

B1 DB contains legal data and the usage of DI API enforces the application of B1

business logic i.e. data integrity and legal compliancy. You cannot access directly

the DB with write operations because in this case you will bypass all the business

logic.

This is strictly enforced by the solution certification guidelines that explicitily do

not allow any direct access to the DB.

[Trinidad]

Hi,

Here you have my thoughts to try to clarify the DI API behavior:

You can use a pool of connections in your addon, there is no problem with it.

The rule to follow is "not to use the same connection in 2 different threads at the same time".

You can open the connection with one thread and use it from another, it shouldn't be a problem.

Hope it helps

Trinidad.

[Former Member]

I'm sure you can lock the table with the first thread, then unlock it when you have finished. I know Oracles can do that, I guess MySQL too. I don't remember clearly but something like that should exist :

http://dev.mysql.com/doc/refman/5.0/en/lock-tables.html

See the link above.

[Former Member]

But using DI-API is about not messing with the database directly. isn't it?

[Gianluigi]

Erez hi -

the issue in DI multithreading is when you want to access concurrently a same

company DB i.e. a same connection

If you have 2 connections for company A and company B then you can have one thread per connection and that will not cause any data corruption: in fact that

makes sense because the thread are ultimately insisting in 2 separate DBs.

But if you have 2 threads on the same connection - and then insisting on the same

DB - this can cause data corruption and you have then to manage the concurrent

access to shared data in order to avoid race conditions.

[Former Member]

Let's see if i get this right..

The only limitation is on using the SAME connection on the SAME database, right?

So let's assume i manage the access to that connection through a custom connection pool, then not more than one thread will be using it concurrently. should this work?

And also, is there a limitation on using the connection only from the thread it was opened in?

[Former Member]

No, this is not correct because 2 different connections could modify the same table at the same time. Well a decent database should have a transaction register that store the commands in a qeue. But until the data has been posted, your changes are not seen by other users. So to keep your database in an up to date state, you are better to lock up your tables.

If SAP can't do that, it's an other thing to change. I don't understand why they put so much limits here ? I prefer to mess with the database then losing my time by finding a way to circumvent SAP's limitations.