cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Laurent Marchal <lmarc...@smaeur.com>
Subject Re: Thread-safe Write DataContext
Date Wed, 26 Mar 2008 16:02:43 GMT
Yep the only problem is that users of the API will have to manually move 
objects between DataContexts, so they will have to know what to do.

I spend this whole day to rewrite the API and pass a datacontext for 
every call.
So I let developers manage their datacontexts.

thanks.

Mike Kienenberger wrote:
> Why not create a new DataContext when you need to do write operations?
>
> On 3/25/08, Laurent Marchal <lmarchal@smaeur.com> wrote:
>   
>> Hi all !
>>
>>  I spent some time searching documentation about the thread-safety status
>>  of DataContext, i found some answers on this mailing list but i would
>>  like to know some details :
>>
>>  I have a big application (Eclipse RCP based) which monitors a database,
>>  so i have to poll the database each 10 seconds.
>>  To be simple i have a single DataContext in my App in :
>>  Session->getDataContext() and i created an API that look like
>>
>>  public static List<User> getAll()
>>  {
>>     SelectQuery q = new SelectQuery(User.class);
>>    try {
>>             return (List<User>)Session.getDataContext().performQuery(q);
>>          } catch(CayenneRuntimeException e  {
>>             //manage exception
>>         }
>>  }
>>
>>  So everywhere the API use a single DataContext no bound to a thread.
>>
>>  Naturally to be reactive the application fetch the data from the
>>  database in a background thread (actually there is one background thread
>>  for each view in the application), and what i've seen is that read
>>  operations are thread-safe within a DataContext so i don't care and all
>>  threads use the API and so the same DataContext.
>>
>>  Here comes the complex part : I need this single DataContext to have a
>>  good cache in my app, and because the application is 90% visualization
>>  and only 10% modifications, so i just had to find a thread-safe
>>  workaround for writing data.
>>  I tried some solutions :
>>  - Bind a DC per thread is not a good solution because all my fetching is
>>  in background threads so the main Session DC (in the UI thread) is never
>>  updated.
>>  - I have tried to create a childDataContext bound to the current thread
>>  for writing, but i had some strange behaviors, and i don't know if the
>>  flushToParent() is thread safe ?
>>
>>  So i would like to know if the new LifecycleListener can be used to
>>  "lock" the DataContext while writing, to have a single thread-safe R/W
>>  DataContext like :
>>
>>  dataContext.getEntityResolver().getCallbackRegistry().addDefaultListener(new
>>  LifecycleListener(){
>>
>>                 Lock lock = new ReentrantLock();
>>
>>                 public void postPersist(Object entity) {
>>                     lock.unlock();
>>                 }
>>                 public void postRemove(Object entity) {
>>                     lock.unlock();
>>                 }
>>                 public void postUpdate(Object entity) {
>>                     lock.unlock();
>>                 }
>>                 public void prePersist(Object entity) {
>>                     lock.lock();
>>                 }
>>                 public void preRemove(Object entity) {
>>                     lock.lock();
>>                 }
>>                 public void preUpdate(Object entity) {
>>                     lock.lock();
>>                 }
>>  });
>>
>>  Do you think it can be a good solution ?
>>
>>  Thanks.
>>
>>
>>  Laurent Marchal.
>>
>>     
>
> _________________________________________________________________________
>
> Ce message a été vérifié par l'antivirus de MDaemon (md6).
>
> Par précaution, n'ouvrez pas de pièces jointes de correspondants inconnus.
> _________________________________________________________________________
>
>
> ___________________________________________________
>
> Ce message a été vérifié par l'antivirus de MDaemon 5 .
>
> Par précaution, n'ouvrez pas de pièces jointes de correspondants inconnus.
> ___________________________________________________
>
>
>   

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message