Hi,
If you want to use optimistic locking with the standard OJB distribution,
you have to have a "locking" field. One approach you could take would be to
create JdbcAccess access implementation which does it's own optimistic
locking; I suggest this as
org.apache.ojb.broker.accesslayer.JdbcAccessImpl is the only place that
OptimisticLockException is thrown.
Another approach (depending on the number of tables, the amount of database
access that is required, and whether your database allows updates on view)
would be to have the locking field stored on an extra table that could be
joined to; create a view that joins the two, and then map your object to the
view. Here's an (untested, hypothetical) example :
CREATE TABLE ORIGINALTABLE (
ID decimal(10,0) NOT NULL,
OJBCONCRETECLASS varchar(255),
NAME varchar(30)
)
CREATE TABLE ORIGINALTABLE_LOCK (
ID decimal(10,0) NOT NULL,
OPTIMISTICLOCK integer
)
CREATE VIEW V_ORIGINALTABLE AS
SELECT ORIGINALTABLE.*, ORIGINALTABLE_LOCK.OPTIMISTIC_LOCK FROM
ORIGINALTABLE
inner join ORIGINALTABLE_LOCK on ORIGINALTABLE_LOCK.ID =
ORIGINALTABLE.ID
<class-descriptor class="example.Thing" table="V_ORIGINALTABLE">
<field-descriptor id="1" name="ID" column="ID" jdbc-type="DECIMAL"
/>
<field-descriptor id="2" name="optimisticLock"
column="OPTIMISTICLOCK" jdbc-type="INTEGER" locking="true" />
<field-descriptor id="3" name="NAME" column="NAME"
jdbc-type="VARCHAR"/>
</class-descriptor>
But basically, yes, you are the first person that I have read about on this
list (in 7 years - first subscribed at sourceforge in 1996...)that needs to
be able to do optimistic locking without having a field that you can use as
a locking field.
Cheers,
Charles.
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 02 February 2004 10:05
> To: OJB Users List
> Subject: Antwort: Optimistic locking / select ... for update
>
>
>
> Hi,
>
> I was asking about experience with optimistic locking a few
> days ago. Has
> really nobody done that before (as the non responses appear to me).
> Problem was I can't use a "locking field" and couldn't find
> anything I can
> use to produce a "select for update".
>
> Lasse
>
>
>
>
>
> |---------+----------------------------------------->
> | | Lasse |
> | | Lambrecht/IS-LF1/Allianz-Leben|
> | | @ALLIANZ-DE |
> | | |
> | | 19.01.04 17:24 |
> | | Bitte antworten an "OJB Users |
> | | List" |
> | | |
> |---------+----------------------------------------->
>
> >-------------------------------------------------------------
> ------------------------------------------------------------------|
> |
> |
> | An: [EMAIL PROTECTED]
> |
> | Kopie:
> |
> | Thema: Optimistic locking / select ... for
> update
> |
>
> >-------------------------------------------------------------
> ------------------------------------------------------------------|
>
>
>
> Hi all,
>
> for a webbased application I need an optimistic locking mechanism. My
> application uses an existing database, so I can't (and don't
> want) add an
> extra locking column to each table.
> How are you others handle this?
> Of Course, I can do the optimistic locking by myself. Saving
> the original
> object somewhere and reread and compare it before saving. But
> in this case
> in need a "select...for update" SQL to be sure the row is not
> modified in
> the meantime. How can I do that with OJB (PB-API prefered).
>
> Regards
> Lasse
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
___________________________________________________________
HPD Software Ltd. - Helping Business Finance Business
Email terms and conditions: www.hpdsoftware.com/disclaimer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
