Anybody face this problem before ?
On Fri, Feb 13, 2009 at 2:41 PM, CG wrote:
> Hi, I encounter a problem with CascadeType for a OneToMany
> relationship, hopefully somebody can help ... Thanks.
>
> I am using OpenJPA 1.0.3 that come with Apache Geronimo 2.1.3
>
>
> Basically , I have a loop to
Philip,
> do the optimistic lock checks for read locks after the INSERT, DELETE,
> and UPDATES for the transaction.
This is currently possible with setting VersionCheckOnReadLock property on
LockManager.
I think this will ensure that all three Flags become part of commit set and
thus the transa
David,
I am afraid that the schema tool will not create the necessary schemas and you
have to do it manually. I had a similar problem with PostgreSQL. This is a
quote from the manual:
"The schema tool manipulates tables, columns, indexes, constraints, and
sequences. It cannot create or drop the
Hi David,
EL does an update for each read lock at commit time, setting its version
column to the same value. See my other post - I agree that SELECT FOR UPDATE
is not appropriate for read locks, and I instead suggest a third approach;
that is to do the optimistic lock checks for read locks after
Pinaki - I agree with David that you're not addressing the purpose of read
locks.
Here's my opinion:
1. Any locking mechanism that is prone to race conditions (no matter
how rare) is useless.
2. Given this, for read locks to add distinct value to that provided
by write locks, I think you have t
