You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Evgeny Ryabitskiy <ev...@gmail.com> on 2009/12/01 13:44:57 UTC

Singletons in Cayenne and problems. Can I use multiple transactions?

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.

Re: Singletons in Cayenne and problems. Can I use multiple transactions?

Posted by Andrus Adamchik <an...@objectstyle.org>.
Sure. I am fine with keeping it as well. I guess this is mainly a  
documentation issue - it has to be mentioned that this is just one  
possible usage pattern, not *the* way to access ObjectContext.

Andrus

On Dec 1, 2009, at 8:51 PM, Michael Gentry wrote:

> I agree with Andrey here.  I think it is better for Cayenne to provide
> this in a consistent/standardized way for those who want it rather
> than requiring people to roll their own each time.  Those who need
> something more complex can implement something more complex, but let's
> keep the common case easy/standard.
>
> mrg
>
>
> On Tue, Dec 1, 2009 at 1:29 PM, Andrey Razumovsky
> <ra...@gmail.com> wrote:
>> 2009/12/1 Andrus Adamchik <an...@objectstyle.org>
>>
>>> 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.
>>>
>>>
>> I'm -1. We can see some profit in moving it from BC class (say, to  
>> new
>> "Cayenne" utility). But I'm sure it is widely used by everyone who  
>> uses
>> Cayenne in web apps (or maybe even in desktop apps)
>>
>


Re: Singletons in Cayenne and problems. Can I use multiple transactions?

Posted by Michael Gentry <mg...@masslight.net>.
I agree with Andrey here.  I think it is better for Cayenne to provide
this in a consistent/standardized way for those who want it rather
than requiring people to roll their own each time.  Those who need
something more complex can implement something more complex, but let's
keep the common case easy/standard.

mrg


On Tue, Dec 1, 2009 at 1:29 PM, Andrey Razumovsky
<ra...@gmail.com> wrote:
> 2009/12/1 Andrus Adamchik <an...@objectstyle.org>
>
>> 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.
>>
>>
> I'm -1. We can see some profit in moving it from BC class (say, to new
> "Cayenne" utility). But I'm sure it is widely used by everyone who uses
> Cayenne in web apps (or maybe even in desktop apps)
>

Re: Singletons in Cayenne and problems. Can I use multiple transactions?

Posted by Andrey Razumovsky <ra...@gmail.com>.
2009/12/1 Andrus Adamchik <an...@objectstyle.org>

> 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.
>
>
I'm -1. We can see some profit in moving it from BC class (say, to new
"Cayenne" utility). But I'm sure it is widely used by everyone who uses
Cayenne in web apps (or maybe even in desktop apps)

Re: Singletons in Cayenne and problems. Can I use multiple transactions?

Posted by Andrus Adamchik <an...@objectstyle.org>.
On Dec 1, 2009, at 6:12 PM, Evgeny Ryabitskiy wrote:

> Transaction is not aggregated
> to DataDomain (inside called static method of Transaction class) how I
> was thinking before.

Well, Domain acts as a factory for the transaction, based on its own  
configuration. In 3.1 we'll have a DI container that is a factory of  
everything. Although there will be 1 DI container per Domain. So it is  
not going to change in 3.1.


> Callbacks can be add after initialization as a set of Delegates (now
> there can be only one so I can't say this transaction is fully
> cross-domain working).

Yeah I also don't like a single delegate model (and may change that in  
3.1). Nothing would prevent you from aggregating multiple delegates  
within one delegate on your own, but since we are talking about  
possible improvements, this is a valid point.

Andrus

Re: Singletons in Cayenne and problems. Can I use multiple transactions?

Posted by Evgeny Ryabitskiy <ev...@gmail.com>.
> if you have ideas,  let's discuss them.

So first my idea is to change this method (It's confusing!!!):

domain.createTransaction();

A spend some time looking through code. Transaction is not aggregated
to DataDomain (inside called static method of Transaction class) how I
was thinking before. Only thing why it's where is parameter with
defines to use External or Internal Transaction and... some Delegate
for callbacks.
If it's singleton and can be used across several DataDomains it should
be more oblivious if we initialize it as a Singleton via static
method.

Callbacks can be add after initialization as a set of Delegates (now
there can be only one so I can't say this transaction is fully
cross-domain working).
What I want to say: If we are using it as Singleton (in scope of one
thread) then let's make it friendly-user singleton, not a headache for
developers who are constructing huge system with multiple domains :)

Evgeny.

>
>>> transactions, and while addressing one use case it breaks others (i.e.
>>> other
>>> users may need a single commit point across multiple DataDomains).
>>
>> Ok. Actually I has no differences between several domain-local
>> transactions and one huge that is across multiple DataDomains.
>> The question is Transaction is working well across multiple DataDomains?
>
> There's nothing magical about Transactions. In Cayenne they are a store of
> JDBC Connection to ensure that multiple sub-operations within a given
> operation get the same connection and consequently operate on the same db
> data version.
>
> 2 possible caveats between domains when they reuse transactions:
>
> * They should both use either external or internal transactions (i.e. the
> same transaction strategy).
> * If they want completely separate connections, DataNode names should not
> match. If they want to reuse connections from each other, they DataNode
> names should match.
>
> Andrus
>
>
>
>
>
>

Re: Singletons in Cayenne and problems. Can I use multiple transactions?

Posted by Andrus Adamchik <an...@objectstyle.org>.
On Dec 1, 2009, at 4:29 PM, Evgeny Ryabitskiy wrote:

> It's a crutch :/

Possibly. If we are to redesign public transaction API in Cayenne,  
let's looks at the big picture then and see what problems we are  
trying to solve. IIRC it was mentioned before that we can make  
*manual* transaction management more user-friendly (automatic is as  
friendly as it gets)... I am not sure how (or rather my ideas go in  
the direction of allowing attaching arbitrary objects to transactions,  
maybe not something you care about), but if you have ideas,  let's  
discuss them.

>> transactions, and while addressing one use case it breaks others  
>> (i.e. other
>> users may need a single commit point across multiple DataDomains).
>
> Ok. Actually I has no differences between several domain-local
> transactions and one huge that is across multiple DataDomains.
> The question is Transaction is working well across multiple  
> DataDomains?

There's nothing magical about Transactions. In Cayenne they are a  
store of JDBC Connection to ensure that multiple sub-operations within  
a given operation get the same connection and consequently operate on  
the same db data version.

2 possible caveats between domains when they reuse transactions:

* They should both use either external or internal transactions (i.e.  
the same transaction strategy).
* If they want completely separate connections, DataNode names should  
not match. If they want to reuse connections from each other, they  
DataNode names should match.

Andrus






Re: Singletons in Cayenne and problems. Can I use multiple transactions?

Posted by Evgeny Ryabitskiy <ev...@gmail.com>.
> So here is how you can address your problem - unbind outer transaction from
> the thread when the nested transaction is started, and then rebind it back
> after inner commit/rollback:
>
> Transaction outer = Transaction.getThreadTransaction();
> try {
>   Transaction inner = ... // create
>   Transaction.bindThreadTransaction(inner);
>
>   ... // do work
> }
> finally {
>   Transaction.bindThreadTransaction(outer);
> }

It's a crutch :/

> transactions, and while addressing one use case it breaks others (i.e. other
> users may need a single commit point across multiple DataDomains).

Ok. Actually I has no differences between several domain-local
transactions and one huge that is across multiple DataDomains.
The question is Transaction is working well across multiple DataDomains?
When I am looking at code and see: someDomain.createTransaction() I
don't expect for this transaction to work across another
DataDomain....

Evgeny.

>
> On Dec 1, 2009, at 3:41 PM, Evgeny Ryabitskiy wrote:
>
>> Manual? I create them manually by calling domain1.createTransaction()
>> and domain2.createTransaction().
>>
>> How it happen: One method from Module 1 do some queries (first domain)
>> then call method from Module 2 that is also doing some queries (second
>> domain), after method from module 2 finished: method from module 1 is
>> doing more queries.
>>
>> So it's like an "nested" transaction (from mod 2) but is performed on
>> another DataDomain (it's another DB server) and absolutely isolated
>> from huge "outer" transaction (mod 1).
>> But I want to control both! and separately...
>>
>> Evgeny.
>>
>>
>>
>> 2009/12/1 Andrus Adamchik <an...@objectstyle.org>:
>>>
>>> Are those manual transactions? (I.e. how does it happen that transaction
>>> scopes overlap between two queries?)
>>>
>>> Also you can reuse the current thread transaction between multiple
>>> domains.
>>> As I said, connections are scoped by DataNode name, so the same
>>> transaction
>>> will return 2 separate connections for 2 queries run against 2 different
>>> nodes.
>>>
>>> Andrus
>>>
>>> On Dec 1, 2009, at 3:27 PM, Evgeny Ryabitskiy wrote:
>>>
>>>> Problem in multiple Domains.
>>>> When I am creating transaction I am creating it's for specific
>>>> DataDomain (like a DataContext).
>>>> When I have 2 Modules with dedicated DataDomains (so it will be 2
>>>> DataDomains) I can create 2 Transactions
>>>> (domain.createTransaction()).
>>>>
>>>> But to thread I can bind only one. Then when I start performing queries
>>>> I
>>>> got:
>>>> 1)First Domain Transaction is binded and handled normally
>>>> 2)Second Domain Transaction is override by first DataDomain. So when I
>>>> perform query for second: ThreadLocals return Transaction for firs
>>>> Domain.
>>>>
>>>> Evgeny
>>>>
>>>>
>>>>
>>>> 2009/12/1 Andrus Adamchik <an...@objectstyle.org>:
>>>>>
>>>>> 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.
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>

Re: Singletons in Cayenne and problems. Can I use multiple transactions?

Posted by Andrus Adamchik <an...@objectstyle.org>.
Calling Cayenne transactions "singletons" is not really accurate, as  
they are thread-local and scoped, and you can control that scope if  
you have to. So here is how you can address your problem - unbind  
outer transaction from the thread when the nested transaction is  
started, and then rebind it back after inner commit/rollback:

Transaction outer = Transaction.getThreadTransaction();
try {
    Transaction inner = ... // create
    Transaction.bindThreadTransaction(inner);

    ... // do work
}
finally {
    Transaction.bindThreadTransaction(outer);
}

I am undecided on whether DataDomain-scoped transactions is a good  
idea going forward. This goes against most J2EE users expectations  
about transactions, and while addressing one use case it breaks others  
(i.e. other users may need a single commit point across multiple  
DataDomains).

Andrus


On Dec 1, 2009, at 3:41 PM, Evgeny Ryabitskiy wrote:

> Manual? I create them manually by calling domain1.createTransaction()
> and domain2.createTransaction().
>
> How it happen: One method from Module 1 do some queries (first domain)
> then call method from Module 2 that is also doing some queries (second
> domain), after method from module 2 finished: method from module 1 is
> doing more queries.
>
> So it's like an "nested" transaction (from mod 2) but is performed on
> another DataDomain (it's another DB server) and absolutely isolated
> from huge "outer" transaction (mod 1).
> But I want to control both! and separately...
>
> Evgeny.
>
>
>
> 2009/12/1 Andrus Adamchik <an...@objectstyle.org>:
>> Are those manual transactions? (I.e. how does it happen that  
>> transaction
>> scopes overlap between two queries?)
>>
>> Also you can reuse the current thread transaction between multiple  
>> domains.
>> As I said, connections are scoped by DataNode name, so the same  
>> transaction
>> will return 2 separate connections for 2 queries run against 2  
>> different
>> nodes.
>>
>> Andrus
>>
>> On Dec 1, 2009, at 3:27 PM, Evgeny Ryabitskiy wrote:
>>
>>> Problem in multiple Domains.
>>> When I am creating transaction I am creating it's for specific
>>> DataDomain (like a DataContext).
>>> When I have 2 Modules with dedicated DataDomains (so it will be 2
>>> DataDomains) I can create 2 Transactions
>>> (domain.createTransaction()).
>>>
>>> But to thread I can bind only one. Then when I start performing  
>>> queries I
>>> got:
>>> 1)First Domain Transaction is binded and handled normally
>>> 2)Second Domain Transaction is override by first DataDomain. So  
>>> when I
>>> perform query for second: ThreadLocals return Transaction for firs
>>> Domain.
>>>
>>> Evgeny
>>>
>>>
>>>
>>> 2009/12/1 Andrus Adamchik <an...@objectstyle.org>:
>>>>
>>>> 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.
>>>>>
>>>>
>>>>
>>>
>>
>>
>


Re: Singletons in Cayenne and problems. Can I use multiple transactions?

Posted by Evgeny Ryabitskiy <ev...@gmail.com>.
Manual? I create them manually by calling domain1.createTransaction()
and domain2.createTransaction().

How it happen: One method from Module 1 do some queries (first domain)
then call method from Module 2 that is also doing some queries (second
domain), after method from module 2 finished: method from module 1 is
doing more queries.

So it's like an "nested" transaction (from mod 2) but is performed on
another DataDomain (it's another DB server) and absolutely isolated
from huge "outer" transaction (mod 1).
 But I want to control both! and separately...

Evgeny.



2009/12/1 Andrus Adamchik <an...@objectstyle.org>:
> Are those manual transactions? (I.e. how does it happen that transaction
> scopes overlap between two queries?)
>
> Also you can reuse the current thread transaction between multiple domains.
> As I said, connections are scoped by DataNode name, so the same transaction
> will return 2 separate connections for 2 queries run against 2 different
> nodes.
>
> Andrus
>
> On Dec 1, 2009, at 3:27 PM, Evgeny Ryabitskiy wrote:
>
>> Problem in multiple Domains.
>> When I am creating transaction I am creating it's for specific
>> DataDomain (like a DataContext).
>> When I have 2 Modules with dedicated DataDomains (so it will be 2
>> DataDomains) I can create 2 Transactions
>> (domain.createTransaction()).
>>
>> But to thread I can bind only one. Then when I start performing queries I
>> got:
>> 1)First Domain Transaction is binded and handled normally
>> 2)Second Domain Transaction is override by first DataDomain. So when I
>> perform query for second: ThreadLocals return Transaction for firs
>> Domain.
>>
>> Evgeny
>>
>>
>>
>> 2009/12/1 Andrus Adamchik <an...@objectstyle.org>:
>>>
>>> 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.
>>>>
>>>
>>>
>>
>
>

Re: Singletons in Cayenne and problems. Can I use multiple transactions?

Posted by Andrus Adamchik <an...@objectstyle.org>.
Are those manual transactions? (I.e. how does it happen that  
transaction scopes overlap between two queries?)

Also you can reuse the current thread transaction between multiple  
domains. As I said, connections are scoped by DataNode name, so the  
same transaction will return 2 separate connections for 2 queries run  
against 2 different nodes.

Andrus

On Dec 1, 2009, at 3:27 PM, Evgeny Ryabitskiy wrote:

> Problem in multiple Domains.
> When I am creating transaction I am creating it's for specific
> DataDomain (like a DataContext).
> When I have 2 Modules with dedicated DataDomains (so it will be 2
> DataDomains) I can create 2 Transactions
> (domain.createTransaction()).
>
> But to thread I can bind only one. Then when I start performing  
> queries I got:
> 1)First Domain Transaction is binded and handled normally
> 2)Second Domain Transaction is override by first DataDomain. So when I
> perform query for second: ThreadLocals return Transaction for firs
> Domain.
>
> Evgeny
>
>
>
> 2009/12/1 Andrus Adamchik <an...@objectstyle.org>:
>> 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.
>>>
>>
>>
>


Re: Singletons in Cayenne and problems. Can I use multiple transactions?

Posted by Evgeny Ryabitskiy <ev...@gmail.com>.
Problem in multiple Domains.
When I am creating transaction I am creating it's for specific
DataDomain (like a DataContext).
When I have 2 Modules with dedicated DataDomains (so it will be 2
DataDomains) I can create 2 Transactions
(domain.createTransaction()).

But to thread I can bind only one. Then when I start performing queries I got:
1)First Domain Transaction is binded and handled normally
2)Second Domain Transaction is override by first DataDomain. So when I
perform query for second: ThreadLocals return Transaction for firs
Domain.

Evgeny



2009/12/1 Andrus Adamchik <an...@objectstyle.org>:
> 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.
>>
>
>

Re: Singletons in Cayenne and problems. Can I use multiple transactions?

Posted by Andrus Adamchik <an...@objectstyle.org>.
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.
>