Mike you left out the obvious one, simply use a conversation framework.
The problem is not transactions but it is that the entity manger is
dropped along the way hence silently detaching all objects and running
you into detached error hell. (You still can either setup your jpa
provider so that
Mike you left out the obvious one, simply use a conversation
framework.
Definitely true, but not always applicable. I would e.g. not recommend using
long running transactions for public pages. This will increase the session
footprint big times and you'll get more easily vulnerable for DOS
Hi Werner,
I tested the problem with newest snapshot from today and it works. It
looks like it was a temporary bug in the trunk. ;-)
Thx for your help!
Marcus
Werner Punz schrieb:
Ok I gave the example a testrun and could not reproduce the problem
anymore, I assume one of following issues
Hi!
I know, I might sound like a broken record already ...
But also consider using a JPA-like persistence provider like Ebean [1].
If you are going to deatach your objects, you can avoid the persistence
context at all.
Ebean just maintains a persistence context per transaction. So, if you are
And, btw, Orchestra is still useful then, but there is no need to attach it
to the PersistenceContext then.
It just acts as a simple conversation scope provider without any magic
associated with the database layer. = easier spring configuration too.
Ciao,
Mario
-Ursprüngliche Nachricht-
Thanks for your response. I have not had a chance to look at the
Facelets example in trunk yet and compare that to my code but it's good
to know it's there. I'll report back once I have some results.
Rossen
On 06/17/2010 11:01 AM, Michael Freedman wrote:
So I tried running the (new)
Hi,
I have the following example:
h:outputLabel for=val1 value=Value1/
h:inputText id=val1
value=#{myBean.val1}
valueChangeListener=#{myBean.val1ChangedListener}
f:ajax render=myText event=change /
/h:inputText
Yes the issue is that you use a command button which in case of a single
button maps automatically to input type=submit if you hit enter
the ajax request is issued and subsequently parallely the full submit is
issued as well.
You can resolve that by using commandlinks or h:commandButton
Hi! I have finally manager to create a very simple test case for my problem.
My issue with data loss seems to be related to the enctype of the form
(multipart/form-data) and the fact that I am loading data using a
preRenderView event.
To reproduce this problem, create a test page:
html
I am not familiar with orchestra, so I can't comment there. It has
not been an option for us up to this point.
However, if you leave a transaction active after a response, it's
always going to be an issue no matter what framework you use.
For us, the problem with holder objects is the deep
Hi
It is not a problem related to orchestra. JSF implementation does not decode
request with enctype=multipart/form-data. Other user reported this on:
https://issues.apache.org/jira/browse/MYFACES-2688
For decode that kind of requests it is necessary to use a filter or a
FacesContextWrapper.
Hi,
I have same problem with CDI a it's conversation.
Please see my comment on
https://issues.apache.org/jira/browse/MYFACES-2688
Best regards,
Martin Kočí
Leonardo Uribe píše v Pá 02. 07. 2010 v 13:31 -0500:
Hi
It is not a problem related to orchestra. JSF implementation does not decode
12 matches
Mail list logo
