Lock table for update in adf
dear all ,
am using Jdeveloper 11.1.1.3 with oracle database 10g,
now what i need to do is when inserting a new row in one of my entities i need to lock the entire database table until the commit happen...
i'll explain to u why I need to do this,,, let say that the table x contains the following columns
x_pk number, ( which is the primary key )
x_serial number,
x_type varchar2 );
now am getting x_pk from a sequence on a database so its not a problem,
but for x_serial it needs to be serialized per x_type , now in oracle forms developer i used to do the following in per-insert trigger on the block level-->
lock table for update then selecting the max serial per the type then use it for setting the :x_serial that is in the same block...
now in ADF , i should do this in the do_dml when the operation==DML_INSERT but am not sure what to write and if it will be working same as it was in the form developer
thanks ,
Lama
Delta,
I wrote a [url http://stegemanoracle.wordpress.com/2006/03/15/using-updatable-views-with-adf/]blog post some time ago for an earlier version of JDeveloper that implemented some custom locking behaviour for EOs - perhaps you can adapt the technique there to your needs?
John
Similar Messages
-
Re: Transactions and Locking Rows for Update
Dale,
Sounds like you either need an "optimistic locking" scheme, usually
implemented with timestamps at the database level, or a concurrency manager.
A concurrency manager registers objects that may be of interest to multiple
users in a central location. It takes care of notifying interested parties
(i.e., clients,) of changes made to those objects, using a "notifier" pattern.
The optimistic locking scheme is relatively easy to implement at the
database level, but introduces several problems. One problem is that the
first person to save their changes "wins" - every one else has to discard
their changes. Also, you now have business policy effectively embedded in
the database.
The concurrency manager is much more flexible, and keeps the policy where
it probably belongs. However, it is more complex, and there are some
implications to performance when you get to the multiple-thousand-user
range because of its event-based nature.
Another pattern of lock management that has been implemented is a
"key-based" lock manager that does not use events, and may be more
effective at managing this type of concurrency for large numbers of users.
There are too many details to go into here, but I may be able to give you
more ideas in a separate note, if you want.
Don
At 04:48 PM 6/5/97 PDT, Dale "V." Georg wrote:
I have a problem in the application I am currently working on, which it
seems to me should be easily solvable via appropriate use of transactions
and database locking, but I'm having trouble figuring out exactly how to
do it. The database we are using is Oracle 7.2.
The scenario is as follows: We have a window where the user picks an
object from a dropdown list. Some of the object's attributes are then
displayed in that window, and the user then has the option of editing
those attributes, and at some point hitting the equivalent of a 'save'button
to write the changes back to the database. So far, so good. Now
introduce a second user. If user #1 and user #2 both happen to pull up
the same object and start making changes to it, user #1 could write back
to the database and then 15 seconds later user #2 could write back to the
database, completely overlaying user #1's changes without ever knowing
they had happened. This is not good, particularly for our application
where editing the object causes it to progress from one state to the next,
and multiple users trying to edit it at the same time spells disaster.
The first thing that came to mind was to do a select with intent to update,
i.e. 'select * from table where key = 'somevalue' with update'. This way
the next user to try to select from the table using the same key would not
be able to get it. This would prevent multiple users from being able to
pull the same object up on their screens at the same time. Unfortunately,
I can think of a number of problems with this approach.
For one thing, the lock is only held for the duration of the transaction, so
I would have to open a Forte transaction, do the select with intent to
update, let the user modify the object, then when they saved it back again
end the transaction. Since a window is driven by the event loop I can't
think of any way to start a transaction, let the user interact with the
window, then end the transaction, short of closing and re-opening the
window. This would imply having a separate window specifically for
updating the object, and then wrapping the whole of that window's event
loop in a transaction. This would be a different interface than we wanted
to present to the users, but it might still work if not for the next issue.
The second problem is that we are using a pooled DBSession approach
to connecting to the database. There is a single Oracle login account
which none of the users know the password to, and thus the users
simply share DBSession resources. If one user starts a transaction
and does a select with intent to update on one DBSession, then another
user starts a transaction and tries to do the same thing on the same
DBSession, then the second user will get an error out of Oracle because
there's already an open transaction on that DBSession.
At this point, I am still tossing ideas around in my head, but after
speaking with our Oracle/Forte admin here, we came to the conclusion
that somebody must have had to address these issues before, so I
thought I'd toss it out and see what came back.
Thanks in advance for any ideas!
Dale V. Georg
Indus Consultancy Services [email protected]
Mack Trucks, Inc. [email protected]
>
>
>
>
====================================
Don Nelson
Senior Consultant
Forte Software, Inc.
Denver, CO
Corporate voice mail: 510-986-3810
aka: [email protected]
====================================
"I think nighttime is dark so you can imagine your fears with less
distraction." - CalvinWe have taken an optimistic data locking approach. Retrieved values are
stored as initial values; changes are stored seperately. During update, key
value(s) or the entire retieved set is used in a where criteria to validate
that the data set is still in the initial state. This allows good decoupling
of the data access layer. However, optimistic locking allows multiple users
to access the same data set at the same time, but then only one can save
changes, the rest would get an error message that the data had changed. We
haven't had any need to use a pessimistic lock.
Pessimistic locking usually involves some form of open session or DBMS level
lock, which we haven't implemented for performance reasons. If we do find the
need for a pessimistic lock, we will probably use cached data sets that are
checked first, and returned as read-only if already in the cache.
-DFR
Dale V. Georg <[email protected]> on 06/05/97 03:25:02 PM
To: Forte User Group <[email protected]> @ INTERNET
cc: Richards* Debbie <[email protected]> @ INTERNET, Gardner*
Steve <[email protected]> @ INTERNET
Subject: Transactions and Locking Rows for Update
I have a problem in the application I am currently working on, which it
seems to me should be easily solvable via appropriate use of transactions
and database locking, but I'm having trouble figuring out exactly how to
do it. The database we are using is Oracle 7.2.
The scenario is as follows: We have a window where the user picks an
object from a dropdown list. Some of the object's attributes are then
displayed in that window, and the user then has the option of editing
those attributes, and at some point hitting the equivalent of a 'save' button
to write the changes back to the database. So far, so good. Now
introduce a second user. If user #1 and user #2 both happen to pull up
the same object and start making changes to it, user #1 could write back
to the database and then 15 seconds later user #2 could write back to the
database, completely overlaying user #1's changes without ever knowing
they had happened. This is not good, particularly for our application
where editing the object causes it to progress from one state to the next,
and multiple users trying to edit it at the same time spells disaster.
The first thing that came to mind was to do a select with intent to update,
i.e. 'select * from table where key = 'somevalue' with update'. This way
the next user to try to select from the table using the same key would not
be able to get it. This would prevent multiple users from being able to
pull the same object up on their screens at the same time. Unfortunately,
I can think of a number of problems with this approach.
For one thing, the lock is only held for the duration of the transaction, so
I would have to open a Forte transaction, do the select with intent to
update, let the user modify the object, then when they saved it back again
end the transaction. Since a window is driven by the event loop I can't
think of any way to start a transaction, let the user interact with the
window, then end the transaction, short of closing and re-opening the
window. This would imply having a separate window specifically for
updating the object, and then wrapping the whole of that window's event
loop in a transaction. This would be a different interface than we wanted
to present to the users, but it might still work if not for the next issue.
The second problem is that we are using a pooled DBSession approach
to connecting to the database. There is a single Oracle login account
which none of the users know the password to, and thus the users
simply share DBSession resources. If one user starts a transaction
and does a select with intent to update on one DBSession, then another
user starts a transaction and tries to do the same thing on the same
DBSession, then the second user will get an error out of Oracle because
there's already an open transaction on that DBSession.
At this point, I am still tossing ideas around in my head, but after
speaking with our Oracle/Forte admin here, we came to the conclusion
that somebody must have had to address these issues before, so I
thought I'd toss it out and see what came back.
Thanks in advance for
any
ideas!
Dale V. Georg
Indus Consultancy Services [email protected]
Mack Trucks, Inc. [email protected]
------ Message Header Follows ------
Received: from pebble.Sagesoln.com by notes.bsginc.com
(PostalUnion/SMTP(tm) v2.1.9c for Windows NT(tm))
id AA-1997Jun05.162418.1771.334203; Thu, 05 Jun 1997 16:24:19 -0500
Received: (from sync@localhost) by pebble.Sagesoln.com (8.6.10/8.6.9) id
NAA11825 for forte-users-outgoing; Thu, 5 Jun 1997 13:47:58 -0700
Received: (from uucp@localhost) by pebble.Sagesoln.com (8.6.10/8.6.9) id
NAA11819 for <[email protected]>; Thu, 5 Jun 1997 13:47:56 -0700
Received: from unknown(207.159.84.4) by pebble.sagesoln.com via smap (V1.3)
id sma011817; Thu Jun 5 13:47:43 1997
Received: from tes0001.macktrucks.com by relay.macktrucks.com
via smtpd (for pebble.sagesoln.com [206.80.24.108]) with SMTP; 5 Jun
1997 19:35:31 UT
Received: from dale by tes0001.macktrucks.com (SMI-8.6/SMI-SVR4)
id QAA04637; Thu, 5 Jun 1997 16:45:51 -0400
Message-ID: <[email protected]>
Priority: Normal
To: Forte User Group <[email protected]>
Cc: "Richards," Debbie <[email protected]>,
"Gardner," Steve <[email protected]>
MIME-Version: 1.0
From: Dale "V." Georg <[email protected]>
Subject: Transactions and Locking Rows for Update
Date: Thu, 05 Jun 97 16:48:37 PDT
Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT"
Content-Transfer-Encoding: quoted-printable
Sender: [email protected]
Precedence: bulk
Reply-To: Dale "V." Georg <[email protected]> -
FM for locking n unlocking a table for update
I have to update a table named bnka, can anyone tel me the FM for locking and unlocking a table before updating the same..
thnkx
amityou can use FM ENQUEUE_EFBNKA to lock the table vbak
and DEQUEUE_EFBNKA to unlock it
Example:
call function 'ENQUEUE_EFBNKA'
EXPORTING
MODE_BNKA = 'E'
BANKS = bnka-banks
BANKL = bnka-bankl
EXCEPTIONS
FOREIGN_LOCK = 1
SYSTEM_FAILURE = 2
OTHERS = 3.
if sy-subrc <> 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
endif.
update BNKA .....
call function 'DEQUEUE_EFBNKA'
EXPORTING
MODE_BNKA = 'E'
BANKS = bnka-banks
BANKL = bnka-bankl. -
Explicit Lock on for Update Table
If I want to perform explicit lock acquiring on updating all records in “customer” table with “state” equals to “CA”. What command should I run?
Hi,
Refer to following ppt.
http://www.indiana.edu/~dbateam/Documents/oracle_locking.ppt#260,5,Oracle Isolation Levels
You can get to know the things.
- Pavan Kumar N -
Transactions and Locking Rows for Update
I have a problem in the application I am currently working on, which it
seems to me should be easily solvable via appropriate use of transactions
and database locking, but I'm having trouble figuring out exactly how to
do it. The database we are using is Oracle 7.2.
The scenario is as follows: We have a window where the user picks an
object from a dropdown list. Some of the object's attributes are then
displayed in that window, and the user then has the option of editing
those attributes, and at some point hitting the equivalent of a 'save' button
to write the changes back to the database. So far, so good. Now
introduce a second user. If user #1 and user #2 both happen to pull up
the same object and start making changes to it, user #1 could write back
to the database and then 15 seconds later user #2 could write back to the
database, completely overlaying user #1's changes without ever knowing
they had happened. This is not good, particularly for our application
where editing the object causes it to progress from one state to the next,
and multiple users trying to edit it at the same time spells disaster.
The first thing that came to mind was to do a select with intent to update,
i.e. 'select * from table where key = 'somevalue' with update'. This way
the next user to try to select from the table using the same key would not
be able to get it. This would prevent multiple users from being able to
pull the same object up on their screens at the same time. Unfortunately,
I can think of a number of problems with this approach.
For one thing, the lock is only held for the duration of the transaction, so
I would have to open a Forte transaction, do the select with intent to
update, let the user modify the object, then when they saved it back again
end the transaction. Since a window is driven by the event loop I can't
think of any way to start a transaction, let the user interact with the
window, then end the transaction, short of closing and re-opening the
window. This would imply having a separate window specifically for
updating the object, and then wrapping the whole of that window's event
loop in a transaction. This would be a different interface than we wanted
to present to the users, but it might still work if not for the next issue.
The second problem is that we are using a pooled DBSession approach
to connecting to the database. There is a single Oracle login account
which none of the users know the password to, and thus the users
simply share DBSession resources. If one user starts a transaction
and does a select with intent to update on one DBSession, then another
user starts a transaction and tries to do the same thing on the same
DBSession, then the second user will get an error out of Oracle because
there's already an open transaction on that DBSession.
At this point, I am still tossing ideas around in my head, but after
speaking with our Oracle/Forte admin here, we came to the conclusion
that somebody must have had to address these issues before, so I
thought I'd toss it out and see what came back.
Thanks in advance for any ideas!
Dale V. Georg
Indus Consultancy Services [email protected]
Mack Trucks, Inc. [email protected]
[email protected]------------------I have a problem in the application I am currently working on, which it
seems to me should be easily solvable via appropriate use of transactions
and database locking, but I'm having trouble figuring out exactly how to
do it. The database we are using is Oracle 7.2.
The scenario is as follows: We have a window where the user picks an
object from a dropdown list. Some of the object's attributes are then
displayed in that window, and the user then has the option of editing
those attributes, and at some point hitting the equivalent of a 'save' button
to write the changes back to the database. So far, so good. Now
introduce a second user. If user #1 and user #2 both happen to pull up
the same object and start making changes to it, user #1 could write back
to the database and then 15 seconds later user #2 could write back to the
database, completely overlaying user #1's changes without ever knowing
they had happened. This is not good, particularly for our application
where editing the object causes it to progress from one state to the next,
and multiple users trying to edit it at the same time spells disaster.
The first thing that came to mind was to do a select with intent to update,
i.e. 'select * from table where key = 'somevalue' with update'. This way
the next user to try to select from the table using the same key would not
be able to get it. This would prevent multiple users from being able to
pull the same object up on their screens at the same time. Unfortunately,
I can think of a number of problems with this approach.
For one thing, the lock is only held for the duration of the transaction, so
I would have to open a Forte transaction, do the select with intent to
update, let the user modify the object, then when they saved it back again
end the transaction. Since a window is driven by the event loop I can't
think of any way to start a transaction, let the user interact with the
window, then end the transaction, short of closing and re-opening the
window. This would imply having a separate window specifically for
updating the object, and then wrapping the whole of that window's event
loop in a transaction. This would be a different interface than we wanted
to present to the users, but it might still work if not for the next issue.
The second problem is that we are using a pooled DBSession approach
to connecting to the database. There is a single Oracle login account
which none of the users know the password to, and thus the users
simply share DBSession resources. If one user starts a transaction
and does a select with intent to update on one DBSession, then another
user starts a transaction and tries to do the same thing on the same
DBSession, then the second user will get an error out of Oracle because
there's already an open transaction on that DBSession.
At this point, I am still tossing ideas around in my head, but after
speaking with our Oracle/Forte admin here, we came to the conclusion
that somebody must have had to address these issues before, so I
thought I'd toss it out and see what came back.
Thanks in advance for any ideas!
Dale V. Georg
Indus Consultancy Services [email protected]
Mack Trucks, Inc. [email protected]
[email protected]------------------ -
Hi ,
i have a program that unite some table to one big table,
and i look for lock those tables while the program is running.
lock table just for editing,the users can watch.
there is a way to do this???Hi,
i did this like that:
FORM locktable USING P_ITAB_TABNAME.
CALL FUNCTION 'ENQUEUE_E_TABLE'
EXPORTING
MODE_RSTABLE = 'E'
TABNAME = P_ITAB_TABNAME
VARKEY =
X_TABNAME = ' '
X_VARKEY = ' '
_SCOPE = '2'
_WAIT = ' '
_COLLECT = ' '
EXCEPTIONS
FOREIGN_LOCK = 1
SYSTEM_FAILURE = 2
OTHERS = 3
IF SY-SUBRC <> 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
ENDFORM. " locktable
and when i'm runnning the program it crash and give me this msg:
CALL_FUNCTION_CONFLICT_TYPE.
what did i do wrong??? -
INV_INSPECTION_FLAG_ERR in the mtl_interface_errors table for UPDATE
Hi ,
I am doing Item UPDATE interface through Back end
i am getting error in the mtl_interface_errors table like below
COLUMN_NAME ERROR_MESSAGE
INSPECTION_REQUIRED_FLAG Inspection Required Flag cannot be set to "Y" if Receipt Routing is not set to Inspection.
what is happening?PranitSaha wrote:
Probably you are using an item template that contains conflicting item attribute values.
Sent from my iPhone
Hi,
Thanks for reply,I am not using Item Template in the Insert statement to the interface table,
I am just inserting into org_id,item_no,process_flag, pr0cess_id...
can you please explain more? -
ORA-00918 issue joining tables for Update
Hi,
I have 2 tables : PAR_SPEC_OPS and T_PAR and I'm trying to update 2 columns in the first one with values from the second table.
Here's my script :
Update
Select membership_id, membership_status
From Par_Spec_Ops P,T_Par T
Where P.Tracking_ID=T.Tracking_ID
Set P.membership_id = T.membership_id,
P.membership_status = T.membership_status;
Running this gives me ORA-00918: column ambiguously defined. I've looked this up and it says it happens when there's a common column in the 2 tables and I'm not using prefixes, but as you can see from my command, I'am using prefixes. I have tried with and without alias but I get the same error.
Do you guys have any ideas?
Thanks and regards,
Ionut
Edited by: 837311 on Nov 8, 2011 4:24 AMDoes this help?
SQL> create table t_par
2 (membership_id number,
3 membership_status varchar2(10),
4 tracking_id number
5 );
Table created.
SQL>
SQL> create unique index t_par_ix1 on t_par(tracking_id);
Index created.
SQL>
SQL> create table par_spec_ops
2 (membership_id number,
3 membership_status varchar2(10),
4 tracking_id number
5 );
Table created.
SQL>
SQL> create unique index tracking_id_ix1 on par_spec_ops(tracking_id);
Index created.
SQL>
SQL> insert into t_par values(111,'new',1111);
1 row created.
SQL> insert into t_par values(222,'new',2222);
1 row created.
SQL> insert into t_par values(333,'new',3333);
1 row created.
SQL>
SQL> insert into par_spec_ops values(111,'expired',1111);
1 row created.
SQL> insert into par_spec_ops values(222,'expired',2222);
1 row created.
SQL>
SQL> Select t.membership_id, t.membership_status,p.membership_id,p.membership_status
2 From T_Par T left outer join par_spec_ops p using(tracking_id)
3 ;
MEMBERSHIP_ID MEMBERSHIP MEMBERSHIP_ID MEMBERSHIP
111 new 111 expired
222 new 222 expired
333 new
SQL>
SQL> Update
2 (
3 Select p.membership_id as p_m_id,
4 t.membership_id as t_m_id,
5 t.membership_status t_m_stat,
6 p.membership_status p_m_stat
7 From Par_Spec_Ops P,T_Par T
8 Where P.Tracking_ID=T.Tracking_ID
9 )
10 Set p_m_id = t_m_id,
11 p_m_stat = t_m_stat;
2 rows updated.
SQL>
SQL> Select t.membership_id, t.membership_status,p.membership_id,p.membership_status
2 From T_Par T left outer join par_spec_ops p using(tracking_id)
3 ;
MEMBERSHIP_ID MEMBERSHIP MEMBERSHIP_ID MEMBERSHIP
111 new 111 new
222 new 222 new
333 new
SQL> -
hi,
Please suggest me the table or procedure to find the Fixed Cost in SALES ORDER COSTING.
the field name is FK,Data element is CK_FK_S1 ,structure is CKCOSTLINE.
Thanks in Advance.Try these tables.
KALA,KALO,KALM -
Table for updating the employee notice period
Hi gurus,
our organisation wants to update the contarct elements..
i.e notice period should be updated as 03 months
deadlines section in infotype 16
but in the drop down list of ER notice period we are having the following entries 01 30 days
02 60 days
03 1 month
04 2 months.
i want to add the 05 entry as 3 months how to do that..
pls help me...maintain V_T547T
-
Wich is table for match between Infoprovider and update with technical name
Thanks in advance!
Bye!
FerdinandoHello ,
You can check table --> RSUPDINFO table for Update rules with tech ID between Cube and InfoSources.
and other ref tables are --> RSUPDROUT / RSUPDDAT / RSUPDKEY /
--EnjoySAP
**Award credits if you are done with my answer -
Oracle Version: 10.2.0.5
O/S : Redhat
Hi,
I have a select statement that is wrapped in the FOR UPDATE NOWAIT clause. This is embedded in a stored procedure and this stored procedure may be called concurrently by multiple threads from a .net application.
Off late i have noticed that the proc has been returning the same value to 2 different calls - this defeats the purpose of row-level locking that FOR UPDATE NOWAIT does. I did notice that the procedure calls from the .net application where 100th of a millisecond apart.
Is there any workaround to avoid the same row being returned to different calls? or is this a known behaviour and i just have to live with it?
Edited by: brainstormer on May 6, 2013 12:56 PMThis is part of the SP that performs the lock, updates the queue table so that record is marked as In Process so it is not returned to another process when it is already In Process.
Thought it may sound far fetched, my theory is that even before session 1 completes the SELECT statement, session 2 comes in and run the select statement. Since session 1 has not completed and has not locked the row yet - oracle returns the same row to both.
Is this a possible scenario?
PRAGMA AUTONOMOUS_TRANSACTION;
lock_detected EXCEPTION;
PRAGMA EXCEPTION_INIT(lock_detected, -54);
BEGIN
BEGIN
SELECT q.request_id, q.process_id
INTO o_request_id, o_process_id
FROM PROCESS_QUEUE q
WHERE q.process_id IN (
SELECT process_id
FROM (
SELECT l.process_id
FROM PROCESS_QUEUE L, REQUESTS r
WHERE L.request_id = r.request_id
AND r.manifest_only = NVL(io_manifest_only,r.manifest_only)
AND r.status = 'INP'
AND ((l.status IN ('PND', 'RTY') AND l.host_name IS NULL AND l.instance_name IS NULL)
OR (l.status = 'INP' AND l.host_name = i_host_name AND l.instance_name = i_process_name))
AND retry_count < i_retry_count
ORDER BY r.updated_dttm asc, l.created_dttm asc
WHERE
ROWNUM =1)
FOR UPDATE NOWAIT;
EXCEPTION
WHEN lock_detected THEN
NULL;
WHEN NO_DATA_FOUND THEN
NULL;
END;
UPDATE PROCESS_QUEUE
SET status = 'INP',
updated_dttm = sys_extract_utc(current_timestamp),
host_name = i_host_name,
instance_name = i_process_name
WHERE process_id=o_process_id;
COMMIT;
END; -
Hi there
when I do a simple select statement like
select * from table
I recieve all the records without a problem
when I add 'for update' like
select * from table for update
this seems to take a long time (I don't actually get a result)
Is there something I'm doing wrong or have I incorrectly set up my oracle server?As you are saying that your normal query is running fine but if you are using query with for update of it takes more time than previous.
But it is normal behaviour of the oracle itself, when you use for update of, oracle put lock on selected row and then dont allow other users to access it unless and untill first user finish the desired task on selected row. It creates delay in response of your for update query.
null -
SM30 and for updating material groups.
Hi,
what is the table for updating with trx SM30 material groups?
Best regardsHi,
Try table T023.It may workout.
Regards,
Rambhupal reddy -
Database select for update locks ADF
Hi,
When a user has initiated an update session in an adf application and locking is optimistic it will acquire a lock on table row using select for update no wait; . But when the user closes a tab the session would not be terminated. Now i know as HTTP is a stateless protocol, we can wait for the timeout and then the lock will be released using a session listener implementation. But if the user instead tries to log in again in a new tab and tries to edit the same record he will receive a message stating that another user already holds a lock on the record which is correct, but is misleading.
So can we rely on javascript for these scenarios that as soon as the user closes the tab the session should be terminated.
Here's a snippet
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/dojo/1.4/dojo/dojo.xd.js" ></script>
<script type="text/javascript">
var unLoad = function() {
dojo.io.script.get({
url:'http://127.0.0.1:7101/myapp/adfAuthentication?logout=true',
timeout:15000,
dojo.addOnWindowUnload(unLoad);
</script>I know this might not work always as it depends on the fact that request might / might not be processed by the server.
Are there any alternate solutions and also reducing the session timeout is ruled out in my scenario.Ramandeep,
So are there other alternatives or solutionsAlternatives or solutions to what, exactly? As Jobinesh has told you, as long as you use optimistic locking, ADF doesn't acquire database locks except in the context of a transaction that is going to be completed in the current HTTP request. You could obviously force ADF to deviate from this if you called "postChanges" during an HTTP request and leave the transaction hanging, but that would just be wrong in an optimistic locking scenario - the solution would be "don't do that."
John
Maybe you are looking for
-
I am cursed by having more than one appleID. I am also finding iCloud to be a very poorly devised system. I keep getting reminders from somewhere posted to my gmail account. I do not want these cluttering up my inbox and so, set about trying to loc
-
[SOLVED] NVidia GT240 HDMI Audio and ALSA
I have an NVidia GT240 video card with HDMI out and I cannot for the life of me get the audio working through it! I've installed the drivers for NVidia (I've managed to load up XBMC and the video works beautifully) but when loading ALSA (aplay -l) th
-
Premiere Elements 13 issue with the mouse on MAC OSX Yosemite 10.10.1 When I select a clip of video and move to a different place in my time line, Premiere Elements 13, will not release the clip from the mouse. The clip follows my mouse movements and
-
IDoc Transport Acknowledge doesn't return to PI 7.0 automatically
Hi all, I realized an Integration scenario in which PI 7.0 generates custom IDocs messages (like MBGMCR) and send them to a SAP system (4.6 C). In particular there are the scenario steps: 1. BPM -> IDoc msg 2. IDoc msg transport ACK -> BPM 3. BPM ->
-
I can't see videos of itunes U in my ipad
Hello I have an ipad 1 with IOS 5, i recently download some videos of itunes U but i can see them in my ipad but if I sinc with itunes I can see them on itunes What's wrong??? Thanks for all