Hi Alex,
no, unfortunately I'm not in San Francisco at the moment :(
Your comments though led me to check my configuration and I realised that I had
set up transactions in Spring even for pure reads which I think we used on our
last project and I never looked at it again. Copy & paste got me a
Still didn't take the time to look into the code :(
By any chance, are you at JavaOne? We might try to check it out together,
what do you think?
Alex
On Fri, May 2, 2008 at 4:01 AM, Adam Hardy <[EMAIL PROTECTED]>
wrote:
> My curiosity finally got the better of me and I put the JPA transaction
> i
My curiosity finally got the better of me and I put the JPA transaction issue to
test, and I have to concur with you.
What threw me off the scent is the update method I have on my business managers,
on which the transactional boundary is set in Spring.
The update() method doesn't sit well wit
It'll probably be around the tx...I've been doing this within Swing apps,
trying to fix the wizard in Netbeans around JSR 295, 296 and JPA.
Come see my presentation at JavaOne on the subject ;)
But I need to see if this can be applied to this situation. I still don't
get how changes done while appl
Alexander Snaps on 02/05/08 10:04, wrote:
On Thu, May 1, 2008 at 5:49 PM, Eric D. Nielsen <[EMAIL PROTECTED]>
wrote:
Alexander Snaps gmail.com> writes:
I know I am repeating myself, but what is getting in the way of NOT
starting
a transaction at all in the case of a validation error... Shou
On Thu, May 1, 2008 at 5:49 PM, Eric D. Nielsen <[EMAIL PROTECTED]>
wrote:
> Alexander Snaps gmail.com> writes:
> > I know I am repeating myself, but what is getting in the way of NOT
> starting
> > a transaction at all in the case of a validation error... Shoudn't the
> > transaction be started
Alexander Snaps gmail.com> writes:
> I know I am repeating myself, but what is getting in the way of NOT starting
> a transaction at all in the case of a validation error... Shoudn't the
> transaction be started much later anyways, and only if validation passed?
Because that doesn't solve the pro
I know I am repeating myself, but what is getting in the way of NOT starting
a transaction at all in the case of a validation error... Shoudn't the
transaction be started much later anyways, and only if validation passed?
On Thu, May 1, 2008 at 4:51 PM, Adam Hardy <[EMAIL PROTECTED]>
wrote:
> Ye
Yes, you're right. There are also several other things lacking that I would find
useful. But I guess it's still version 1.
Alexander Snaps on 01/05/08 15:35, wrote:
Am I wrong, or JPA's EntityManager has no support for anything like
evict()? I think this is an Hibernate's Session specific feat
Am I wrong, or JPA's EntityManager has no support for anything like
evict()? I think this is an Hibernate's Session specific feature...
Alex
On Thu, May 1, 2008 at 3:54 PM, Eric D Nielsen <[EMAIL PROTECTED]> wrote:
> [ I suspect this is going to break threading Is there a good way to
> respo
Eric D Nielsen on 01/05/08 14:54, wrote:
[ I suspect this is going to break threading Is there a good way to respond
to a message from a digest without breaking threading? )
I wondered why! Unfortunately you need the message id for threading and I don't
think it is included in the digest,
[ I suspect this is going to break threading Is there a good way to respond
to a message from a digest without breaking threading? )
Adam Hardy on 26/04/08 10:42, wrote:
> I am pulling in what I wrote earlier because I should correct what I said
> about letting entities slip out of scope. Fol
Don't really have the context indeed, I haven't been looking into the
Model-Driven and had no clue where this is happening. I just think this is
more correct than doing everything within the tx demarcation. And indeed
many people don't know about the tx.begin - commit in a row thing. I also
keeps e
Alexander Snaps on 01/05/08 12:02, wrote:
Entity myEntity = em.find(Entity.class, someId);
oldValue = myEntity.getSomeField(); // this is only for further down in the
mail ;)
myEntity.setSomeField(someValue);
if(!hasError) {
EntityTransaction tx = em.getTransaction();
tx.begin();
tx.comm
Alexander Snaps on 01/05/08 12:02, wrote:
On Thu, May 1, 2008 at 12:49 PM, Adam Hardy <
[EMAIL PROTECTED]> wrote:
Alexander Snaps on 01/05/08 11:30, wrote:
Using the JPA extended persistence context (not EJB), the clear() will
eliminate any changes to the model before JPA comes to flush to th
On Thu, May 1, 2008 at 12:49 PM, Adam Hardy <
[EMAIL PROTECTED]> wrote:
> Alexander Snaps on 01/05/08 11:30, wrote:
>
> >
> > >
> > > Using the JPA extended persistence context (not EJB), the clear() will
> > > eliminate any changes to the model before JPA comes to flush to the
> > > db. I
> > > a
Alexander Snaps on 01/05/08 11:30, wrote:
Using the JPA extended persistence context (not EJB), the clear() will
eliminate any changes to the model before JPA comes to flush to the db. I
assume it would work in an EJB container too.
I'm not really sure I get the point your making here, but i
Alexander Snaps on 01/05/08 11:30, wrote:
Using the JPA extended persistence context (not EJB), the clear() will
eliminate any changes to the model before JPA comes to flush to the db. I
assume it would work in an EJB container too.
I'm not really sure I get the point your making here, but i
>
>
>
> Using the JPA extended persistence context (not EJB), the clear() will
> eliminate any changes to the model before JPA comes to flush to the db. I
> assume it would work in an EJB container too.
>
I'm not really sure I get the point your making here, but if you just do not
want the EntityM
Chase on 01/05/08 06:04, wrote:
Adam Hardy wrote:
the problem was spurious JPA updates - which can be avoided by putting
an interceptor in between the Validation and the Workflow
interceptors: all it should do is call EntityManager.clear().
if (validationAwareAction.hasErrors()) getEntityM
Adam Hardy wrote:
the problem was spurious JPA updates - which can be avoided by putting
an interceptor in between the Validation and the Workflow
interceptors: all it should do is call EntityManager.clear().
if (validationAwareAction.hasErrors()) getEntityManager().clear();
Using the JPA
Adam Hardy on 26/04/08 10:42, wrote:
Jeromy Evans on 26/04/08 04:51, wrote:
Eric D Nielsen wrote:
I've been investigating some interesting behavior regarding model-driven
actions and found a past thread that covers the situation from late last
year:
http://www.nabble.com/ModelDriven-CRUD-valid
Another possible solution I want to try exploring (but unfortunately its
Hibernate specific) is making a custom version of the validator interceptor:
Inject the session into the interceptor
Call session.readOnly(entity,true) on failed validation
If I'm reading things correctly this should
a) kee
Chase on 26/04/08 20:29, wrote:
Adam Hardy wrote:
Chase on 26/04/08 11:16, wrote:
One solution could be to use a TypeConverter to instantiate new,
unmanaged entities during the ParamsInterceptor invocation.
Such a TypeConverter could pass back instantiated, blank entities
(with nothing but t
Adam Hardy wrote:
Chase on 26/04/08 11:16, wrote:
I also stumbled across this problem.
One solution could be to use a TypeConverter to instantiate new,
unmanaged entities during the ParamsInterceptor invocation.
Such a TypeConverter could pass back instantiated, blank entities
(with noth
8 6:34 AM
To: "Struts Developers List"
Subject: Re: Fundamental flaw in Model-Driven?
Jeromy Evans on 26/04/08 04:51, wrote:
I haven't had an opportunity to absorb your suggestion properly yet but
thought I'd mention I agree with your line of thinking that the
validation mechanism in
Jeromy Evans on 26/04/08 04:51, wrote:
I haven't had an opportunity to absorb your suggestion properly yet but
thought I'd mention I agree with your line of thinking that the
validation mechanism in particular needs to be improved. However, this
is a general problem that also applies to rich cl
Chase on 26/04/08 11:16, wrote:
I also stumbled across this problem.
One solution could be to use a TypeConverter to instantiate new,
unmanaged entities during the ParamsInterceptor invocation.
Such a TypeConverter could pass back instantiated, blank entities
(with nothing but the ID) for
I also stumbled across this problem.
One solution could be to use a TypeConverter to instantiate new,
unmanaged entities during the ParamsInterceptor invocation.
Such a TypeConverter could pass back instantiated, blank entities
(with nothing but the ID) for ParamsInterceptor to collate, an
Jeromy Evans on 26/04/08 04:51, wrote:
Eric D Nielsen wrote:
I've been investigating some interesting behavior regarding model-driven
actions and found a past thread that covers the situation from late last
year:
http://www.nabble.com/ModelDriven-CRUD-validation-failure-still-causes-JPA-update-
Eric D Nielsen wrote:
I've been investigating some interesting behavior regarding model-driven actions
and found a past thread that covers the situation from late last year:
http://www.nabble.com/ModelDriven-CRUD-validation-failure-still-causes-JPA-update-td12987242.html
...
It would seem to be
Could you do what you propose with a custom interceptor stack? Make your
first call to getModel() return a serialized copy of the model object
and the second call return the managed instance. Internally the action
would maintain the reference to the managed instance from the time of
the first g
I've been investigating some interesting behavior regarding model-driven actions
and found a past thread that covers the situation from late last year:
http://www.nabble.com/ModelDriven-CRUD-validation-failure-still-causes-JPA-update-td12987242.html
First I outline the problem, then a possible fra
33 matches
Mail list logo
