Singletons are bad in a general purpose framework, like Cayenne. No
question about that. Per your description even thread-local singletons
can be a problem, which is less obvious to me, but I guess real in
some circumstances. So let's see what those are.
> 2)DataContext.getThreadLocal()
> Solved by own ThreadLocal for each module. (modules can work in one
> thread)
> //also spend some time
This is just a convenience in Cayenne. Nobody's forced to use it. I
will go as far as to suggest to remove it from Cayenne 3.1 as a built-
in feature, and just document it as a possible design pattern in a
user application.
> 3)Transaction.getThreadTransaction()
> this is killing one!!!
> using of own ThreadLocal doesn't help.
> It's hard-coded in performing Query to use this singleton
> Transaction.getThreadTransaction()
> And that is really huge problem for me.
J2EE pattern of tying a transaction to an execution thread, even if
multiple data sources are involved, makes sense as it allows to commit/
rollback multiple things at once. Cayenne Transaction sort of follows
that. JDBC connections within the transaction are scoped by DataNode
name. So what exactly is the problem?
Andrus
On Dec 1, 2009, at 2:44 PM, Evgeny Ryabitskiy wrote:
> Hello 2 everyone!
>
> Today I one more time thinking about singleton pattern and it's hard
> usssage in Cayenne.
>
> So.. I have several modules, each has own DomainConfig file and
> connection to it's DataBase. Sometimes there can be used different DB
> servers and even different DB types (usually it's Oracle and MS SQL,
> sometimes Sybase).
>
> Singletons:
> 1) Configuration.getSharedConfiguration()
> This problem is solved:
> DefaultConfiguration conf = new DefaultConfiguration("module1-
> cayenne.xml");
> conf .initialize;
> conf.getDomain();
> //spend some time to find solution... everywhere examples with
> SharedConfiguration
>
> 2)DataContext.getThreadLocal()
> Solved by own ThreadLocal for each module. (modules can work in one
> thread)
> //also spend some time
>
> 3)Transaction.getThreadTransaction()
> this is killing one!!!
> using of own ThreadLocal doesn't help.
> It's hard-coded in performing Query to use this singleton
> Transaction.getThreadTransaction()
> And that is really huge problem for me.
>
> So me suggestion is to move this ThreadLocal to DataDomain. Still can
> use singleton API for standalone applications.
> Also we can move DataContext to DataDomain.
>
> Evgeny.
>
This archive was generated by hypermail 2.0.0 : Tue Dec 01 2009 - 08:06:53 EST