One .fire() equates one HTTP request. You can .append() request contexts,
but then only one of them can be fire()d (you'll have an exception
otherwise).
Otherwise, yes, one session will have several transactions, possibly
unrelated, but that's the whole point of "batching" things in a
RequestC
Thanks for the reply. I was thinking of doing something similar but the
problem I can see is that the session could possible encapsulate several
different unrelated transactions because of the way RequestFactory handles
appending of different .fire() calls (at least from what I understand of
t
See also:
http://code.google.com/p/google-guice/wiki/JPA
guice-persist supports the "open session in view" pattern, too
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To view this discussion on the web visit
https://groups.google.com/d
I never used JPA or JDO with RF, and I don't know those technologies that
much, but I think what you need is the "open session in view" pattern [1]
to maintain a single session for the whole HTTP request, and then use one
transaction per service method.
[1]
see
http://static.springsource.org/
Is there a way for us to easily do this? In other words is there one method
which I can mark which starts and ends the session for one request?
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To view this discussion on the web visit
http
Thanks Thomas, that's the solution I was looking for too.
The 'solution' I am using now to prevent the lookup before returning
each object was to populate an 'ephemeral' object. I simply create a
duplicate object using the same EntityProxy class and it returns to
the client without doing the looku
RF processes "invocations" (method calls) without knowledge of what they do,
and their can be several such invocations in the same request
(RequestContext).
Imagine I do:
ctx.foo(entity).fire(...);
RF will check whether 'entity' is still 'live', because it cannot know what
'foo' made of it: u
Sorry, I don't exactly understand what you mean. Deleted by whom? Let's say
there is a request for a list of objects which I retrieve from my
web-service. Why does RF need to check if these objects have not been
deleted even though my service has just delivered them as being valid? I
feel like
Note that it's not about "integrity check", the goal is only to detect a
deleted entity and thus dispatch the appropriate EntityProxyChange event on
the client-side.
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group,
Thanks a lot Thomas!
You've just made my day. Currently we don't need the live check, because all
integrity checks are already performed by the backend, so i'll just return
true in isLive. Now I should be able to use a single proxy for crud and list
operations in most cases.
Have a nice day
Jer
Before sending the response back to the client, RF will ask each EntityProxy
it has seen whether it's still "live"; and if it's not, it'll tell the
client that the entity has been deleted (generating an
EntityProxyChange(DELETED) event on the client-side). This is done by asking
the entity's Lo
I've been thinking some more about your remarks and all my solutions are
dead-ends:
- use EntityProxies for all objects. Not possible because I cannot execute a
complete RF server call in a single Hibernate session (because Hibernate
runs one a different server encapsulated by web services)
- us
Thanks a lot Colin,
sounds logical to me, but unfortunately it does not fit at all into our
system design. All our RF requests are piped through HttpInvoker beans to
our Spring-powered backend (which is shared by many different applications,
so I cannot touch it) which of course manages the Hibe
My understanding is that RF assumes you will be using the same persistence
session for the duration of the request to prevent any perf issues here.
Those find operations are done because RF considers the ID to be the only
valid way to know that it has the latest copy of the object - every time i
«Draculaboyman»*
El may 3, 2011 2:02 a.m., "Jerome Thoma" escribió:
> Hi everyone,
> I have a question about EntityProxy vs. ValueProxy and efficiency issues.
I
> need to load a list of SubProxy objects using RF for display in a listbox
> inside an editor for an encompassing SuperProxy type. No Su
>From me
«Draculaboyman»*
El may 3, 2011 2:02 a.m., "Jerome Thoma" escribió:
> Hi everyone,
> I have a question about EntityProxy vs. ValueProxy and efficiency issues.
I
> need to load a list of SubProxy objects using RF for display in a listbox
> inside an editor for an encompassing SuperProxy t
Hi everyone,
I have a question about EntityProxy vs. ValueProxy and efficiency issues. I
need to load a list of SubProxy objects using RF for display in a listbox
inside an editor for an encompassing SuperProxy type. No SubProxy instance
is modified by the editor, but because RF does not support
17 matches
Mail list logo
