Hi Lukas, I see two main categories of ExecuteListeners: - Stateless ExecuteListener. - Stateful ExecuteListener, for example to collect statistics.
My problem is with stateful ExecuteListener. In 2.x, we were registering ExecuteListener classes, which acted like a factory of ExecuteListener instances, and a new instance was created for each query execution. This allowed to declare states directly in the ExecuteListener class. In case we wanted central collection of statistics over time (about all query executions), we could use a statistic cache of some sort. In 3.0 RC2, we register a listener instance instead of a factory. This is not a problem for stateless ExecuteListener, but it becomes problematic for stateful ExecuteListener. While it simplifies cases like central collection over time, it complexifies keeping states local to a single query execution. Indeed, many threads could concurrently invoke the ExecuteListener, and even for a single thread it seems there are cases where a new execution can take place before the previous execution completes (e.g.: fetchLazy() results in end() being called late). Thus, how can we store (and retrieve in each event) a state object that only lives for the time of a query execution? It seems that the ExecuteContext instance is per query execution so get/setData sounds like a logical fit. But it seems that the actual data is potentially not stored in the ExecuteContext itself and could be shared and as such cannot be used to solve this problem. If the data were stored in the context, then we would not have to perfom any cleanup. The other possibility/workaround would be to retain the state in an identity map in the ExecuteListener which key is the context (stored in start() and removed in end()). What I don't like is that we have to make sure that end() is called in every case (e.g.: interruption of fetchLazy, etc) so that we can perform state cleanup, or worse, implement the cache with soft references and a thread that occasionaly cleans dead references. On a related note, I don't see why ExecuteContext.getData() restricts keys to Strings. It could as well be Object, with a contract on whether hashcode/equals is used or something else. Lukas and others (especially if someone is using stateful listeners), any thoughts? Cheers, -Christopher -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
