cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Kienenberger <mkien...@gmail.com>
Subject Re: Change data by an external process (non cayenne)
Date Fri, 24 May 2013 14:04:37 GMT
If you're planning to do this for a web app, you should make sure it
happens before your regular web app is handed the request.   In older
versions of BasicServletConfiguration worked, but I don't think that
class still exists.   One way that should work in any version is to
put it in a servlet filter than runs before your web app's servlet.  I
don't think you''d want to call this code more than once per request.


On Fri, May 24, 2013 at 4:15 AM, Markus Reich
<markus.reich@markusreich.at> wrote:
> Hi,
>
> I can't find the BasicServletConfiguration class, should I override
> the BaseContext.getThreadObjectContext() method, for checking external
> changes in db?
>
> Meex
>
>
> 2013/5/16 Mike Kienenberger <mkienenb@gmail.com>
>
>> Something to keep in mind for web apps is that you probably do not
>> want to have a data refresh at some arbitrary point during a request,
>> only at the beginning of a request.  It's generally better to have
>> your data be a second or two out of date than to have the value of an
>> object or object's relationships change mid-stream while you are
>> working with it.
>>
>> I've been using the LAST_EXTERNAL_UPDATE method for several years now,
>> and I haven't had any regrets.   I've considered changing it over to
>> jms or a similar notification framework, but there weren't any
>> compelling reasons to do so.   This way there's no dependencies in the
>> external processes (most of which are not maintained or written by
>> me), and it's also easy to manually execute a database update and
>> insure that the change will become visible to the active web sessions
>> immediately.   On the other hand, external changes to our database are
>> rare.   Normally only a couple times a day.
>>
>>
>> On Thu, May 16, 2013 at 1:34 PM, Andrus Adamchik <andrus@objectstyle.org>
>> wrote:
>> > Actually if cross-context events are in effect (which is the default),
>> invalidating an object from a given ObjectContext will automatically
>> invalidate it across peers.
>> >
>> > I would still approach it via query cache and cache groups though. All
>> that is needed is that all contexts access those objects via a query
>> instead of storing a direct reference.
>> >
>> > Andrus
>> >
>> > On May 16, 2013, at 12:14 PM, Markus Reich <markus.reich@markusreich.at>
>> wrote:
>> >
>> >> :-) sorry, I try it more detailed
>> >>
>> >> I have a multiuser Tomcat Webapp, the DB (Oracle) is also updated by
>> other
>> >> processes. A refresh is not enough to show the changed data, so my idea
>> is
>> >> to make a servlet, which invalidates certain DataObjects (mostly it's
>> just
>> >> one) of all thread binded contexts.
>> >> So when the user refreshes the UI and the data gets selected again, the
>> >> changed values are shown.
>> >> So it would be enough to make object hollow.
>> >>
>> >> Markus
>> >>
>> >>
>> >> 2013/5/16 Andrus Adamchik <andrus@objectstyle.org>
>> >>
>> >>> The question is too generic, so the answer is "yes" :) Could you
>> describe
>> >>> the scenario in a bit more detail?
>> >>>
>> >>> Also does your interface needs to know when an object is invalidated
>> right
>> >>> at that moment or is it enough to make the object "hollow" so that it
>> is
>> >>> refetched lazily on next access?
>> >>>
>> >>> Andrus
>> >>>
>> >>> On May 16, 2013, at 7:52 AM, Markus Reich <markus.reich@markusreich.at
>> >
>> >>> wrote:
>> >>>> would it be possible to work with a servlet to invalidate certain
>> >>> objects?
>> >>>>
>> >>>> Is there a way to get all ObjectStores of all Threads or is the
only
>> >>>> solution to set the DataContext as attribute in the session?
>> >>>>
>> >>>>
>> >>>> 2013/5/15 Andrus Adamchik <andrus@objectstyle.org>
>> >>>>
>> >>>>> I'd use query.setCacheStrategy(..) / query.setCacheGroups(..)
to
>> cache
>> >>> the
>> >>>>> results, and then define expiration time for a given set of
cache
>> groups
>> >>>>> for whatever cache provider is in use (EhCache most likely,
so this
>> >>> will go
>> >>>>> into ehcache.xml).
>> >>>>>
>> >>>>> If you want real-time refresh, EhCache might be configured to
listen
>> to
>> >>>>> cache group refresh events via JMS. Your external process would
send
>> >>> such
>> >>>>> events via ActiveMQ (that supports a bunch of command-line friendly
>> >>>>> protocols, not just JMS) whenever the data is changed.
>> >>>>>
>> >>>>> Andrus
>> >>>>>
>> >>>>>
>> >>>>> On May 15, 2013, at 4:28 PM, Markus Reich <
>> markus.reich@markusreich.at>
>> >>>>> wrote:
>> >>>>>
>> >>>>>> Hi,
>> >>>>>>
>> >>>>>> is there really no better way than described here:
>> >>>>>> http://markmail.org/message/plnaj4zj4gxrt6hk
>> >>>>>>
>> >>>>>> regards
>> >>>>>> Meex
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> *Markus Reich*
>> >>>> Moosbach 28/2
>> >>>> 6392 St. Jakob i.H.
>> >>>> www.markusreich.at / www.meeximum.at
>> >>>> markus.reich@markusreich.at
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> *Markus Reich*
>> >> Moosbach 28/2
>> >> 6392 St. Jakob i.H.
>> >> www.markusreich.at / www.meeximum.at
>> >> markus.reich@markusreich.at
>> >
>>
>
>
>
> --
> *Markus Reich*
> Moosbach 28/2
> 6392 St. Jakob i.H.
> www.markusreich.at / www.meeximum.at
> markus.reich@markusreich.at

Mime
View raw message