Hello Sander,
I understand what you intend to do. I just don't see (yet) how it's
possible. Before continuing, I'm sure we agree that providing
registries is optional, and in case jOOQ couldn't find a registry, it
will still throw the DetachedException when an unattached object is
stored/refreshed/deleted/executed, right?
Of course, the registry's implementation is up to the user. jOOQ will
only provide an interface. But how does the magic happen? Say you have
an attachable A. And you have two databases DB1 and DB2. Now A is
available in both DB1 and DB2 (by the SchemaMapping functionality). Of
course, you are right, the attachables can hook into deserialisation,
so once they are materialised again, they will ask the registry for a
Configuration or Factory. But what can they pass to the registry? A,
for instance doesn't know whether it belonged to DB1 or DB2 anymore,
as that information was session-dependent, or in the scope of jOOQ's
client code. So how can the registry provide the correct
Configuration? Or is that entirely up to the client code?
Maybe, you could provide me with a descriptive prototype? Is this what you mean?
interface FactoryRegistry {
void attachMe(Attachable attachable) throws NotAttachableException;
}
2011/5/3 Sander Plas <[email protected]>:
> 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.
