Well in go that's sort of how I currently do things: The ConnectionPool/Cache hands out PlcConnectionLeases ... these have the same interface as a PlcConnection, but are only a proxy to a real connection ... you can use it as every other connection, as soon as you call close, it's given back to the Pool/Cache and the connection in the lease is removed. If you then continue to use the connection, you get errors/panics/Exceptions.
I think we should do it like in JDBC or normal database connection pools ... so grab a connection, do something atomically with it and give it back as soon as you're done with it. Now managing concurrency on a universal connection level is unmanageable, I think ... cause, this would need to know for each protocol, which operations are an Atomic unit. Chris -----Original Message----- From: Niclas Hedhman <[email protected]> Sent: Freitag, 21. Januar 2022 17:53 To: [email protected] Subject: Re: [DISCUSS] What should the "Connection Pool" be named? 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
