Given that it is read-mostly, you might be able to get by with a single
DataContext, but unless you have a valid use-case (and they do exist --
I just switched to a single DataContext/database in my biggest utility
application) for only having one, I'd suggest using one-per-client.
It'll isolate changes, allow you to use DB connection pooling, scale
better, etc. In general, it is a cleaner approach for most cases and
requires you to do less work.
/dev/mrg
PS. In case you are wondering, the reason I switched to a single
DataContext is because I need to manage thousands of database objects
(per database), the majority of which are single (1 row returned) SELECT
statements which takes a LONG time to fetch. The application is
read-mostly and all clients share the same objects for
performance/caching. Modifications made by one client are immediately
available to the others and I had to use synchronize methods to control
access to modifying the data. It is also a low-volume
(request/response) application, so I'm not worried about a ton of
clients.
-----Original Message-----
From: Dave Merrin [mailto:dmerri..pasystems.co.uk]
Sent: Monday, January 23, 2006 9:49 AM
To: cayenne-use..bjectstyle.org
Subject: RE: Multiple Data Contexts?
Hi,
currently I have a client server architecture. The client is a java
applet
which does nothing more than call an api on the server. The server then
does
all the database work. I was wondering whether this would need a
DataContext
per client connection or whether a single DataContext could service all
client connections.
The architecture may well be expanded to have web applications. I'm not
entirely sure about the architecture for this part at the moment.
As for the transactions the client will mainly be querying the database
rather than doing any updates. That is why I haven't looked too far into
the
container manager transactions.
Does this help explain a little more?
Cheers,
Dave
> -----Original Message-----
> From: Gentry, Michael (Contractor)
[mailto:michael_gentr..anniemae.com]
> Sent: 23 January 2006 14:32
> To: cayenne-use..bjectstyle.org
> Subject: RE: Multiple Data Contexts?
>
>
> I'm not sure what your application is trying to do, but if it is
> session-based (web application), you generally want at least one
> DataContext per session. Also, many portions of DataContext are
> synchronized, such as commitChanges(), so you wouldn't have 10
parallel
> commits within a single DataContext. A commitChanges does all of it's
> work within a single transaction unless you are using the container
> managed transactions, which relies on the container for transaction
> management.
>
> If you could tell us a bit more about what you are trying to
accomplish,
> we could provide more advice.
>
> /dev/mrg
>
>
> -----Original Message-----
> From: Dave Merrin [mailto:dmerri..pasystems.co.uk]
> Sent: Monday, January 23, 2006 7:00 AM
> To: cayenne-use..bjectstyle.org
> Subject: Multiple Data Contexts?
>
>
> Hi,
>
> I'd like to know if it is worth creating any more than one DataContext
> for
> the same database? i.e. if I want to be able to run 10 database
queries
> at
> once is there any need for 10 DataContext objects? Will the underlying
> connection pooling sort this out for me?
>
> What would happen if I brought in a transaction system to deal with
> database
> transactions? Would starting a transaction automatically take one of
the
> connections for the entire period the transaction is open?
>
> Cheers,
>
> Dave
>
This archive was generated by hypermail 2.0.0 : Mon Jan 23 2006 - 10:25:28 EST