You are viewing a plain text version of this content. The canonical link for it is here.
Posted to torque-dev@db.apache.org by Thomas Fischer <Fi...@seitenbau.net> on 2005/02/07 09:20:14 UTC
cvs organisation: HEAD as active development branch
Hi,
As some vigilant watchers of the dev mailing list might have noticed, I
have merged the cvs TORQUE_3_1_BRANCH into HEAD last week. In the last
days, I got the runtime testcases running against mysql and postgres, and
they also do run against oracle. So I am quite confident that I did not
introduce big mistakes in the merge process.
Considering the amount of changes, I would propose to call the next release
3.2, and therefore abandon the TORQUE_3_1_BRANCH.
If someone feels it necessary to do further commits to the
TORQUE_3_1_BRANCH, PLEASE also commit the changes to HEAD, if it makes any
sense.
Thanks,
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: cvs organisation: HEAD as active development branch
Posted by Thomas Vandahl <th...@tewisoft.de>.
Hi Thomas,
Thomas Fischer wrote:
> and I am unsure whether I should commit it. I do not use LargeSelect
> myself, and have no idea of its uses. It seems to me that a
> ConcurrentModificationException can only be raised if two query threads are
> launched at the same time for the same LargeSelect. In this case, I am not
> sure whether it suffices to synchronize the access to the results object,
> or whether only one select thread should be active at a time. (I do not
> know whether it is desired that one query thread can possibly change the
> results of another running query thread).
LargeSelect is made to retrieve a list of objects in the background
while the Velocity template already can display the first page of
results. This is very handy for paging through long lists of objects.
The said Exception occurs if the background thread still adds objects to
the result list while Velocity already uses an Iterator on the sublist
of the first page. This usually happens when selects take a while.
The patch simply copies the page of results instead of returning a
sublist. This avoids the problem described above and just needs a little
bit more memory.
I have this working in a production environment for almost a year with
no problems whatsoever.
> Regarding the ObjectWithManager patch, I am reluctant to commit the manager
> patch without a testcase, because I do not use the manager myself and have
> no experience with it. I have even seen the runtimetest fail with the cache
> switched on, and therefore consider it buggy. Do you use it in production ?
Yes I do.
Caching is a good idea in database environments, especially in Data
Warehousing. Although the Torque implementation leaves some features to
be desired in this area, I consider the managers a big advantage. JCS
does a good job in providing efficient cache algorithms. I see cache hit
rates of more than 80% in some cases. It is quite useable.
Cache invalidation is a little bit clumsy, however.
> Either some other committer who is more experienced than me in usinfg the
> cache is willing to commit this, or I'd rather see a scarab issue opened
> and have either a testcase or a detailed description of the faulty
> behaviour.
The patch just fixes a Velocity syntax bug, nothing substantial. The
generated save(Connection con) method misses the cache update call in
this case. The bug was introduced fairly recently in Rev 1.15 in an
attempt to fix the generated code for tables without PKs. Torque 3.1.1
works fine.
I consider this bug serious as it breaks the cache management. I will
open an issue in scarab.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: cvs organisation: HEAD as active development branch
Posted by Thomas Fischer <fi...@seitenbau.net>.
Thomas,
thanks for the reminder. I have reviewed the patch (first occurrence is in
the mail archives at
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=torque-user@db.apache.org&msgNo=1111),
and I am unsure whether I should commit it. I do not use LargeSelect
myself, and have no idea of its uses. It seems to me that a
ConcurrentModificationException can only be raised if two query threads are
launched at the same time for the same LargeSelect. In this case, I am not
sure whether it suffices to synchronize the access to the results object,
or whether only one select thread should be active at a time. (I do not
know whether it is desired that one query thread can possibly change the
results of another running query thread).
I'd value Scott's comment on this before I do anything.
Regarding the ObjectWithManager patch, I am reluctant to commit the manager
patch without a testcase, because I do not use the manager myself and have
no experience with it. I have even seen the runtimetest fail with the cache
switched on, and therefore consider it buggy. Do you use it in production ?
Either some other committer who is more experienced than me in usinfg the
cache is willing to commit this, or I'd rather see a scarab issue opened
and have either a testcase or a detailed description of the faulty
behaviour.
Thanks,
Thomas
Thomas Vandahl <th...@tewisoft.de> schrieb am 15.02.2005 14:56:43:
> Hi Thomas
>
> Thomas Fischer wrote:
> > I will commit the patch in the next days. Remind me if I forget it.
> Reminder! :-)
>
> As you are at it: I've got one more thing to patch. I found that the
> latest generator templates do not generate a cache update during
> save(con) correctly because of a failing #set statement. Diff attached.
>
> Bye, Thomas.
>
> --- ObjectWithManager.vm.orig Tue Feb 15 14:36:14 2005
> +++ ObjectWithManager.vm Tue Feb 15 14:36:40 2005
> @@ -1107,7 +1107,11 @@
> ${table.JavaName}Peer.doUpdate(($table.
> JavaName) this, con);
> }
>
> - #set ($tableHasPrimaryKey = $table.PrimaryKey.size() > 0)
> + #if ($table.PrimaryKey.size() > 0)
> + #set ($tableHasPrimaryKey = "true")
> + #else
> + #set ($tableHasPrimaryKey = "false")
> + #end
> #if ($tableHasPrimaryKey)
> #set ($interfaceName = $table.JavaName)
> #if ($table.Interface)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-dev-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: cvs organisation: HEAD as active development branch
Posted by Thomas Vandahl <th...@tewisoft.de>.
Hi Thomas
Thomas Fischer wrote:
> I will commit the patch in the next days. Remind me if I forget it.
Reminder! :-)
As you are at it: I've got one more thing to patch. I found that the
latest generator templates do not generate a cache update during
save(con) correctly because of a failing #set statement. Diff attached.
Bye, Thomas.
Re: cvs organisation: HEAD as active development branch
Posted by Thomas Fischer <fi...@seitenbau.net>.
Hi Thomas
I will commit the patch in the next days. Remind me if I forget it.
Thomas
Thomas Vandahl <th...@tewisoft.de> schrieb am 09.02.2005 19:31:37:
> Hi Thomas,
>
> > Considering the amount of changes, I would propose to call the next
release
> > 3.2, and therefore abandon the TORQUE_3_1_BRANCH.
> > If someone feels it necessary to do further commits to the
> > TORQUE_3_1_BRANCH, PLEASE also commit the changes to HEAD, if it makes
any
> > sense.
>
> Would you please introduce the attached patch into LargeSelect.java. It
> was posted here in the list some time ago by someone else and deals with
> the infamous ConcurrentModificationException in the thread code. I
> thought the patch had made it already into the CVS but I found it
> missing in the new HEAD.
>
> (BTW: Your join patches work quite well in my application. The tests
> were all successful!)
>
> Bye, Thomas.
> --- LargeSelect.java.orig Wed Feb 9 19:22:04 2005
> +++ LargeSelect.java Wed Feb 9 19:28:48 2005
> @@ -624,7 +624,13 @@
> + "fromIndex + Math.min(size, results.size() -
> fromIndex) ("
> + toIndex + ")");
> }
> - List returnResults = results.subList(fromIndex, toIndex);
> +
> + List returnResults;
> +
> + synchronized (results)
> + {
> + returnResults = new ArrayList(results.
> subList(fromIndex, toIndex));
> + }
>
> if (null != returnBuilderClass)
> {
> @@ -705,9 +711,12 @@
> List tempResults
> = BasePeer.getSelectResults(qds, size, false);
>
> - for (int i = 0, n = tempResults.size(); i < n; i++)
> + synchronized (results)
> {
> - results.add(tempResults.get(i));
> + for (int i = 0, n = tempResults.size(); i < n; i++)
> + {
> + results.add(tempResults.get(i));
> + }
> }
>
> currentlyFilledTo += tempResults.size();
> @@ -717,7 +726,10 @@
> // on the last page but we must now get rid of it.
> if (results.size() == memoryLimit + 1)
> {
> - results.remove(currentlyFilledTo--);
> + synchronized (results)
> + {
> + results.remove(currentlyFilledTo--);
> + }
> perhapsLastPage = false;
> }
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-dev-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: cvs organisation: HEAD as active development branch
Posted by Thomas Vandahl <th...@tewisoft.de>.
Hi Thomas,
> Considering the amount of changes, I would propose to call the next release
> 3.2, and therefore abandon the TORQUE_3_1_BRANCH.
> If someone feels it necessary to do further commits to the
> TORQUE_3_1_BRANCH, PLEASE also commit the changes to HEAD, if it makes any
> sense.
Would you please introduce the attached patch into LargeSelect.java. It
was posted here in the list some time ago by someone else and deals with
the infamous ConcurrentModificationException in the thread code. I
thought the patch had made it already into the CVS but I found it
missing in the new HEAD.
(BTW: Your join patches work quite well in my application. The tests
were all successful!)
Bye, Thomas.