cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Kienenberger" <mkien...@gmail.com>
Subject Re: Thread-safe Write DataContext
Date Wed, 26 Mar 2008 16:49:57 GMT
Ok.  You said you had an application, not an API.   You're right that
you'd have to train developers in that situation or find another way
to do it.

On 3/26/08, Laurent Marchal <lmarchal@smaeur.com> wrote:
> 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
View raw message