Only good news :). I have a first window on my application where I can
search for items and then I can change each item on popup window. Do you
think it will work if I create the write-context when I create the
popup, copy into it the object, do all sorts of changes and commit
everything when I
On Jan 24, 2011, at 1:26 PM, Bruno René Santos wrote:
> I'll try to modify the CommitChanges and CommitChangesToParent in order to
> create a very short lived context to where I copy all modifiedObjects and
> deletedObjects in order to commit them.
There should be no modified or deleted object
Great. I'll try to modify the CommitChanges and CommitChangesToParent in
order to create a very short lived context to where I copy all
modifiedObjects and deletedObjects in order to commit them. But what
about the commit order on the DB? the change graph is followed on the
new context? The pro
On Jan 24, 2011, at 1:04 PM, Bruno René Santos wrote:
> So the best way to do this is to keep my shared DataContext for reading and
> when I need to change something I create a new DataContext, pass the object
> read to this new context (using for instants an ObjectIdQuery) and commit on
> thi
So the best way to do this is to keep my shared DataContext for reading
and when I need to change something I create a new DataContext, pass the
object read to this new context (using for instants an ObjectIdQuery)
and commit on this new Context. To refresh the read-only Context with
the change
This is wrong. You shouldn't be sharing a read/write DataContext between
requests. I can't say with 100% certainty that this is causing this particular
problem, but it is guaranteed to cause various consistency issues.
I often use a pattern of 1 shared app-scoped DataContext for reads, and the
In the init() phase of each portlet (I'm using liferay) I call the
DataContext.createDataContext() to create a DataContext that is used
throughout the application (always the same instance, I create an object
that is passed as parameter to all other objects). And yes my app is not
readonly but
> I am developing a web application so it is possible that some thread is
> interfering on the refreshing of the Object Cache?
This depends on how you share a DataContext. If your app is not read-only,
DataContext should not be shared.
Andrus
On Jan 24, 2011, at 12:09 PM, Bruno René Santos wr
HoVPlanoContas is a view. And yes the id 129 exists. On that piece of
code you're expecting a committed object but you're getting a modified
one... I am going to analyze a little further why on this region of code
this happens (On other parts I dont get this error). But it would help
to know th
Can you confirm that there is a record for HoVPlanoContas in the database with
id of 129? Is it reproducible?
Andrus
On Jan 24, 2011, at 3:03 AM, Bruno René Santos wrote:
> Hello all,
>
> Im having an error when I access an object:
>
> Caused by: org.apache.cayenne.FaultFailureException: [v.3
Hello all,
Im having an error when I access an object:
Caused by: org.apache.cayenne.FaultFailureException: [v.3.0.1 Aug 25
2010 19:38:17] Error resolving fault for ObjectId:
and state (modified). Possible cause -
matching row is missing from the database.
at
org.apache.cayenne.BaseCont
11 matches
Mail list logo
