----- Original Message ----- From: "Henning Voss" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, March 27, 2003 3:37 PM Subject: Re: [castor-dev] long transactions without cache
> hi, > > >> > >> > Hi Robin, > >> > > >> > >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >> > > >> > --- cut --- > >> > > >> > >> > >> > >> I don't think you missing something obvious. But why don't you > >> > >> want any caching on you're objects ? > >> > > >> > I have two different (real-world) scenarios: > >> > > >> > - A standalone application loading data from an xml-file and update the > >> > objects in the database (so there can not be a 'old' version in the > >> > cache). > >> > I can workaround this problem by loading the objects in another > >> > transaction > >> > and use a second transaction to update (Database.update(Object)) the > >> > elements. > >> > > >> > - A web application is developed to view and edit data which is edited > >> > also > >> > by an exisiting application. The data in the web-application > >> should always > >> > be up to date. Decreasing the cache-timeout increases Cache-Misses > >> > (->unable > >> > to update) while increasing the cache-timeout leads to obsolete data. > >> > > >> > >> > >> > >> Good luck, > >> > >> > >> > >> Robin Hoogeboom > >> > >> > >> > >> > >> > >> > > --- cut --- > > >> > >> > >> How many transactions are we talking about ? Is it a high-volume > >> application?. If you're cache timeout is small enough, the cache > >> is flushed > >> and Castor is using data from database and not from cache. > >> If the application has not that many transactions, it is save to > >> work this > >> way. > > We are talking about a very low-volume transaction database. This seems to > me more like a fundamental design question (or understanding problem). I > want to use castor to edit data from a web application. The user session > timeout will be around half an hour. So the items in the cache have to stay > in the cache for at least an half our (or I will get an > ObjectModifiedException). But this implies that changes done by another > application are not visible for half an hour. The users will not tolerate > such a behaviour of the applications. > Castor throws an Exception (ObjectModifiedException) if any changes occur during this half an hour. So you may read the object from the database again and send it back to your user if such an exception occurs. Your application can hold the old data as well... so your user can choose to override.... It's how your application deals with it... how would you do it without using Castor. Don't you think you have the same problem(s) ? > I guess that everybody using a combination of a web-application and a > legacy-application will face this problem and can not use castor. Can > someone confirm this ? > > >> > >> Another way is to use OQL instead. Castor doesn't use it cached > >> data if you > >> use an OQL to update or read. > > How do i do this ? I tried something like > OQLQuery xOql = db.getOQLQuery( "SELECT x FROM castortest.X x WHERE > x=1" ); > and > x = (X)db.load(X.class, new Integer(1)); > You don't have to use db.load, you have to execute your brand new OQL query (and put the results in a QueryResults object) http://www.castor.org/api/org/exolab/castor/jdo/OQLQuery.html > Both read the value from the cache, not from the (manually changed) > database. > > >> > >> I also have found some in the list, who can flush the cash on an certain > >> time. It is also an possibility. > > But flushing the cache results in ObjectModifiedExceptions. Flushing your cache, means you have to refresh your read from the database. The ObjectModifiedException is throwed by Castor , if it is not able to track down any changes on db according to your object. Castor is not able to track down any change, if you have no cache to compare the db with. It's the only way to use an Long Transaction. > > >> > >> Good luck. > >> > >> > >> > >> Robin > >> > > sorry for bothering you again, No problem. > Henning > Robin ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
