This one time, at band camp, Alexey A. Efimov said:
AAE>I know about two problems with long transactional support:
AAE>The first problem - is closing QueryResults after db.commit(). But, I
AAE>think, is good, because if you use lazy loading and browse QueryResults
AAE>in "offline", that should be doing Castor in this case? The method,
AAE>about you said - with return Collection of objects (BTW, it must be
AAE>List, not collection, I guess). So, Castor will load full objects for
AAE>you to place it to offline Collection and return it out of transaction.
I was actually thinking of an ArrayList which is a Collection and a
List. But you are correct. It would need to be a List like so:
List queryResultsCopy = new ArrayList();
AAE>Advantages of this:
AAE>- Easy to use resultset returned from query
AAE>
AAE>Disadvantages:
AAE>- Memory peeks (because loaded all objects)
Yes, this could impose more memory used. Now we're starting to hit on
some of the reasons why I wanted more justification for this feature. I'd
like to hear opinions like this so that we can flesh out the design
right here on the list.
AAE>The functionality you ask is can be implemented for you in your code
AAE>like this:
AAE>
AAE> /**
AAE> * Execute OQL query in separate transaction and store results to an
AAE>array list.
AAE> * Access mode to database is used from <code>mapping.xml</code>
AAE>setted for whole
AAE> * class. If access mode not setted in <code>mapping.xml</code>, then
AAE>used "shared"
AAE> * access mode ([EMAIL PROTECTED] Database#Shared})
AAE> * @param oql Oql string (must be not null)
AAE> * @param scrollable Support for cursor in results if true
AAE> * @return List of results
AAE> * @see Query#execute(boolean)
AAE> * @see org.phantom.castorFramework.oql.OQLPreparator
AAE> */
AAE> public List execute(String oql, boolean scrollable) {
AAE> assert oql != null;
AAE>
AAE> Database db = null;
AAE> try {
AAE> // Try execute
AAE> db = getDatabase();
AAE> db.begin();
AAE>
AAE> Query query = db.getOQLQuery(oql);
AAE> ArrayList results = Collections.list(query.execute(scrollable));
AAE>
AAE> db.commit();
AAE>
AAE> return results;
AAE> } catch (Exception ex) {
AAE> throw new JDOException("impl.executeError", new Object[]{oql},
AAE>ex);
AAE> } finally {
AAE> closeDatabase(db);
AAE> }
AAE> }
AAE>
AAE>The second problem of long transaction is the loading object from
AAE>database to lock them, as I can see.
AAE>Now, If you have object outsize of transaction you must to do update
AAE>this, first load old version from database, copy all fields from new to
AAE>old and call db.update.
AAE>
AAE>MyClass o;
AAE>db.begin();
AAE>o = (MyClass)db.load(MyClass.class, "id");
AAE>db.commit();
AAE>
AAE>....
AAE>
AAE>db.begin();
AAE>Object transO = (MyClass)db.load(MyClass.class, o.getId());
AAE>copyObjTo(o, transO);
AAE>db.update(transO);
AAE>db.commit();
The logic above doesn't make sense to me. Why are you calling db.load()
on the same object twice in two different transactions? In the first
transaction you've loaded object o. I assume that in between the two
transactions object o gets changed. Then in the second transaction
you should just be able to call db.update( o ). Why is the copyObjTo()
method needed? Am I missing something here?
AAE>Would be best if update doing just like this:
AAE>db.begin();
AAE>db.update(o);
AAE>db.commit();
AAE>
AAE>This also may implements by you, but more code needed:
AAE>You must implement method copyObj or somethink like this, also you
AAE>needed method to get identity of object to load previos version.
AAE>
AAE>My resume about problems of long transaction:
AAE>1. I think, and it my private opinion, that providing aditional method
AAE>in OQLQuery interface is not significant, becose it do not improve
AAE>Castor performance as whole, but it maybe make life is easiest :)
Making life easier was the reason that this issue arose.
AAE>2. This is requered method, becose otherside implementation of copyObj,
AAE>may be slow or wrong logic, jperation of updating outside of transaction
AAE>object is very important.
I'm not sure I follow the above statement. Please elaborate further.
Bruce
--
perl -e 'print unpack("u30","<0G)[EMAIL PROTECTED]&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
