cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Willerding <awillerd...@itsurcom.com>
Subject Re: Standalone app, Threads and Object contexts
Date Wed, 02 May 2012 20:52:57 GMT
On 05/02/2012 04:26 PM, Michael Gentry wrote:
> We should change that wording in the documentation. Thanks for 
> pointing it out. 
I'm glad I could contribute something!
> 200 threads simultaneously using a DataContext is going to be bad. You 
> want 200 DataContexts. Also, you don't need to initialize the shared 
> configuration every time you create a DataContext. Just once should be 
> fine. When you create a DataContext, it doesn't open/close a 
> connection to the database. Doing dataContext.performQuery() or 
> dataContext.commitChanges() (and similar fetch/commit calls) will get 
> a database connection from the connection pool, use it, then return it. 

How do I create the 200 new DataContexts?  (This is where I came to the 
conclusion that a createChildContext() call was needed.)   Is is simply 
a matter of doing a DataContext.createDataContext() inside of a 
thread?   Will the new DataContexts use the SharedConfiguration of the 
first DataContext that was created? (This is why I thought I needed to 
specify the underlying cayenne.xml file for each DataContext)


> If you have a maximum of 20 connections and you have 20 simultaneous 
> fetches/commits going on, the 21st will have to wait or fail. If you 
> use the DBCPDataSourceFactory method (instead of 
> DriverDataSourceFactory), you get more control in configuring such 
> things. See http://cayenne.apache.org/doc/dbcpdatasourcefactory.html 
> and cayenne.dbcp.maxWait, for example. Keep in mind a DataContext only 
> grabs a database connection when it actually needs to talk to the 
> database. If your request takes 1000ms to process, but only needs 
> 100ms of database connection usage time, that's 900ms of time where 
> the DataContext is not using a connection and another 
> thread/DataContext can use the connection. Furthermore, of that 100ms 
> of database connection usage time, let's imagine that you first do a 
> fetch which takes 20ms and then you do an update which takes 80ms. The 
> DataContext is going to checkout (and checkin) the database connection 
> from (and to) the pool twice: once for the select, once for the 
> update. You may get the same connection the second time or perhaps a 
> different connection. In this manner connections can be shared/re-used 
> among different DataContexts.

I will look further into the DBCPDataSourceFactory method to see what I 
need to learn there!

Mime
View raw message