I'm not really sure what you mean with 'sessions' and why it's relevant in this context. How does an Attachable know its 'session' in the current situation?
Do you perhaps mean that we need a reference to a J2EE/HTTP/Wicket session to get a (pooled) JDBC connection? As far as i know that's not strictly necessary. Wicket for instance has static methods to retrieve things like the current session or the current request cycle. All i'm proposing is to (optionally) replace the current "ad hoc" or "user driven" factory.attach(AttachableObject) calls with something that is driven by the Attachable. After all, the Attachable knows whether it's detached or not and whether it needs to be attached for the task that it is trying to perform, so it should be able to shout "help, i need a factory!" when appropriate - for example when record.store() is called after deserialization. By delegating the re-attachment (and possibly recreation) of Factories to a user definable FactoryRegistry or something like that, the whole logic of how Factories are created or retrieved and what JDBC connections are used is still the responsibility of the user - just as it is now. For example, if an application accesses two separate databases, it will already have two separate JDBC connections and thus 2 separate jOOQ factories in the current situation, so it's easy to pass separate FactoryRegistries (either completely separate implementations or just separate, differently configured instances - it's up to the user) to those factories to ensure that the right database gets connected to the right Attachable on deserialization. BTW, i don't think your earlier remark "jOOQ doesn't know when / how objects are serialised." is entirely true. AFAIK you can hook into the serialization/deserialization process by overriding the readObject() and writeObject() methods. So, i guess it's probably also possible to immediately re-attach attachables on deserialization.
