[prev in list] [next in list] [prev in thread] [next in thread] 

List:       turbine-torque-dev
Subject:    Re: cvs organisation: HEAD as active development branch
From:       Thomas Vandahl <thomas.vandahl () tewisoft ! de>
Date:       2005-02-15 17:24:48
Message-ID: 42123060.80607 () tewisoft ! de
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]