Concurrent Access To Record.

I'am working on a typical workflow application .

Records can be added ,Updated , sanctioned, Authorized,

Deleted & viewed.

Business rules are :-

1)Only fresh & Sanctioned records can be modified

2)Only Sanctioned records can be Authorized

3)Only non Authorized records can be updated

4)Only non Authorized records can be Cancelled

5)Only non Authorized records can be Deleted.

Now assuming i want to Delete a non Authorized record,

I populate my transaction screen in Delete mode .

What i am actually doing is populating a Vector[]

from the database with field values for the particular record

and displaying it on the transaction screen

Now before I Delete this record if another user

Authorises the same record , my application logic goes for a toss.

This is because at the time both the records were

selected from the search screen , they were both

fresh records & both Deletion and Authorization was

possible .

How do i take care of this scenerio ?

I know that i could take care in the Delete Query by using the not in

Keyword & specify the required record status there .

but is there a cleaner way to do this ....

-

Another Fundamantal Question I have is

Typically , Entity Beans stand for

1) State of one row in the database

2) Listing Behaviour ( A Ship bean will have

a method which list's all it's cabin entity beans)

Now the question i have here is

client 'A' get's a remote referance to a Ship bean calls getCabins(),

and then loops & populates a select drop down in a JSP with the available cabins on a Ship . Assume the list diplays 100 cabins.

Simultaneously another user 'B' books a reservation on the

same ship & consequently there are only 99 free cabins.

What measure's should we take to ensure that Client 'A'

is not affected.He may as well select the same cabin as

the one selected by the Client 'A' & book a reservation.

How are web application's designed to handle this Scenerio ?

Basically in both my queries , what is happening is that the

Database is updated by another user before the first user

commits. How to tackle this scenerio ? any typical examples

+ sites mentioning explanations would are welcome.

Please gurus guide me ...as i am a newbie .!

[2509 byte] By [silentscream] at [2007-9-27 19:22:54]
# 1

Hi,

For the first problem, when you get the records, you should lock it exclusively so that no one else can update or delete it before you're done with it. You can do that either by starting a transaction or by creating an exclusive lock for the record.

For the second problem, consider different application flow - Instead of presenting the user with a list of available cabins, ask them how many cabins they want to reserve, and then check availability and reserve the cabin(s) (if available).

Hope this helps

dstavrakov at 2007-7-6 22:07:32 > top of Java-index,Other Topics,Patterns & OO Design...
# 2
Hi,Use Transactions to avoid to avoid concurrent updates and have the Transaction isolation level set to SERIALIZABLE. I think this should solve ur basic problem.neo
neo79119 at 2007-7-6 22:07:32 > top of Java-index,Other Topics,Patterns & OO Design...
# 3

Hi,

> Use Transactions to avoid to avoid concurrent updates

> and have the Transaction isolation level set to

> SERIALIZABLE.

Absolutely write to do as per my understanding.Let me explain this in detail with the actual post:

When two programms are attempting t access the database simultaneously following problems can crop up

1)Client A transaction reads the row ,Client B modifies the row,Client A reads the row again and finds the different result..THis is the case of the "NONREPEATABLE READ"

2) Client A transaction selects a set of rows as per some search criteria,Client B transaction inserts a row specifying the same search criteria,Client A transaction now executes the query again.This is the case of the "PHANTOM READS"

3)Client A transaction modifies a row,Client B transaction reads the same data,Client A transaction now does the rollback and row disappears .This is the case of the "DIRTY READ"

Now TRANSACTION_READ_UNCOMMITED allows all cases

TRANSACTION_READ_COMMITED permits nonrepeatable reads and phantom reads

TRANSACTION_REPEATABLE_READ allows only phantom reads

TRANSACTION_SERIALIZABLE does not permit any of the cases......

hope this helps you.....

regards

vicky

vickyk at 2007-7-6 22:07:32 > top of Java-index,Other Topics,Patterns & OO Design...