Andrus, thanks a lot you for looking into this.
That is quite a pile of bugs I am running into here. First this MySQL JDBC
driver bug returning java.lang.Long for any auto-increment column, then
cayenne treating 'INT UNSIGNED' as an Integer. Now issues with
Hi Juergen,
I assume you have 2 DbEntities with the same name, mapped to
different ObjEntities (otherwise it wouldn't have worked in 1.1
either). Actually you can work around that issue by putting
conflicting entities in two different DataDomains, as domains do not
share EntityResolvers.
Well, since this is your visit (session) instance, shouldn't only one
thread at a time be accessing the list?
/dev/mrg
On 9/29/06, Øyvind Harboe [EMAIL PROTECTED] wrote:
Where can I read more about Cayenne and behaviour of objects when
accessed from multiple threads simultaneously?
We've
DataContext is not thread-safe, as it is intended for access by a
single user.
DataDomain and the rest of the stack underneath the DataContext is
thread-safe.
If a there is a chance of multiple threads belonging to the same user
to access the context (and its DataObjects) simultaneously,
On 9/29/06, Michael Gentry [EMAIL PROTECTED] wrote:
Well, since this is your visit (session) instance, shouldn't only one
thread at a time be accessing the list?
I thought so. But the evidence is that my assumption is broken. I
haven't found documentation that clearly explains the Tapestry
On 9/29/06, Andrus Adamchik [EMAIL PROTECTED] wrote:
DataContext is not thread-safe, as it is intended for access by a
single user.
DataDomain and the rest of the stack underneath the DataContext is
thread-safe.
If a there is a chance of multiple threads belonging to the same user
to access
Yeah, there is quite a few bugs involved.
First an explanation on Cayenne strategies... Long works with
auto_increment as long as the driver supports it, but doesn't not
work with any other strategy, as all of them are based on overriding
int JdbcPkGenerator.pkFromDatabase(..).
What we
The Tapestry rules, as I understand them, are when a request comes in,
it can access the visit (session) and that object is associated only
for that request (which is running in a thread) for the duration of
the request. If you have your DataContext in the visit only, there
should be no spill
The multi-threading going on in tapestry (at least for tap3) is nothing
more than the normal multi-threading in servlet programming: each
request is handled by a separate thread. The only extra thread tapestry
(3; can't speak for 4) starts is the janitor thread which cleans up
the pool.
As
Alternately, you can use a servlet filter and disallow concurrent
requests to the same session:
import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import
ah ok, thanks for clarifying this.
was this MySQL no Locking PkGenerator ever implemented?
*
Hmm, I got so far with the AUTO_INCREMENT set up, I don't want to drop it so
quickly.
From reading the Sequoia docs I don't get why the sequoia jdbc driver returns
different meta data than the
We have tried to incorporate all the issues people have had with the
initial design into this updated design:
http://www.brucemartin.net/cayenne/
It achieves a few things:
* reduce the size of the left menu to not make it overwhelming
* increase the size of the left menu to give more choices
12 matches
Mail list logo
