Here is how I would create the abstraction;
There are "physical connections" from the PLC4X to zero, one or more
devices, and a single connection is held to each device. Then we need a
solution where different threads can access each such physical
connection in an ordered/shared manner. So, the client API hands over a
"virtual connection" which knows how to coordinate with the virtual
connection (and that implementation is hidden from API, and can change
over time, and completely different for different drivers, and possibly
even configurable for different device types).
The "Virtual driver" is very very light, and no pool is needed. No cache
is needed. Straight up "request a connection, hold on to it for as long
or as short as you want, then release it".
Cheers
Niclas
On 2022-01-21 12:35, Christofer Dutz wrote:
Hi all,
in the past we had a "ConnectionPool" ... but in reality, we don't
have a pool of multiple connection to one target, like in databases,
but usually we have only one connection to each source in the "pool".
But we can have multiple connections to multiple targets.
I guess that's why Julian named the new version of the Pool
"Connection Cache". This sort of comes closer to what it technically
is.
So now the question is: How should we generally name this thing?
I would opt to stick with ConnectionPool despite it being more a
ConnectionCache. The reason for this is that people looking for
something with the functionality, will probably start looking for a
ConnectionPool and not a ConnetionCache. I think the inside nature of
the component is more a context-detail and we should rather provide
people with what they intuitively would look for.
But I would like to hear your thoughts on this.
Chris
