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.re...@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 <mkien...@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 <and...@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.re...@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 <and...@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.re...@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 <and...@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.re...@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.re...@markusreich.at >> >>> >> >>> >> >> >> >> >> >> -- >> >> *Markus Reich* >> >> Moosbach 28/2 >> >> 6392 St. Jakob i.H. >> >> www.markusreich.at / www.meeximum.at >> >> markus.re...@markusreich.at >> > >> > > > > -- > *Markus Reich* > Moosbach 28/2 > 6392 St. Jakob i.H. > www.markusreich.at / www.meeximum.at > markus.re...@markusreich.at
