[redhat-ccm-list] CCM - Transactions. Please Help!!

[Randy Graebner]

srini wrote:

>Randy,
>
>How I can I do the following:
>
>1. In a transaction, create a domain object, save it to DB 
>
>2. With this transaction still NOT committed, be able to retrieve the
>   instance (created in step one) from within another transaction opened
>   by a background thread (it is NOT a nested transaction)
>
>I need some way to dissociate/unlock the created instance (in step one)
>so
>that it can be retrieved in step 2 above. Is committing the first
>transaction the only way to do that??
>
>  
>
That is correct.  If you open up two sqlplus windows (or psql windows 
with auto-commit turned off) you will notice that inserts in the first 
window do not appear in "select" results in the second window until the 
transaction in the first windows is completed. 

If you don't want to share transactions then due to the nature of a 
transaction, the only way for a new transaction to see the information 
is for the first transaction to commit.  So, you could: 1. have your 
background thread wait for the commit to occur, 2. explicitly commit the 
transaction creating the data right after the save (there are some 
complications with doing this but it is definitely possible) or 3. have 
your background check to see if there is a currently running transaction 
and if so, use that, otherwise, use its own.    I would personally 
prefer option 1 since options 2 and 3 both have problems with them.  
But, you should decide based on your given requirements.

Randy



>Thank you for your quick response
>
>Srinivas
>
>
>-----Original Message-----
>From: Randy Graebner [mailto:randyg at redhat.com] 
>Sent: Friday, May 14, 2004 10:49 AM
>To: srini
>Cc: 'Vadim Nasardinov'; redhat-ccm-list at redhat.com
>Subject: Re: [redhat-ccm-list] CCM - Transactions. Please Help!!
>
>srini wrote:
>
>  
>
>>Here is what I do in my web app:
>>
>>1. Whenever a logged in user submits a job, I create an JOB instance
>>  in the database (using domain object), do an explicit disconnect
>>  of this instance and put into a Job Queue (in memory)
>>
>>2. A thread monitors this Job Queue and processes each job in the
>>    
>>
>queue.
>  
>
>>  Since the stored job instances (in the queue are READ ONLY), I then
>>  retrieve the job details again from the database using this
>>  READ ONLY object's ID. That is when I run into this exception.
>>
>>  (IMPORTANT: I can see the job details in the database)
>>
>>
>> 
>>
>>    
>>
>Is it possible that the thread has its own transaction and is actually 
>opening the transaction before the domain object transaction is 
>committed?  In that situation, the line will appear in the DB but may 
>not be available to the background thread.
>
>The reason that we are thinking that there may be an overlapping 
>transaction or some other issue like that (and not necessarily a problem
>
>with the disconnect() call) is that when you call "get" on an object 
>that has lost its transaction then you get a different error...one that 
>explicitly states that that the transaction is lost...it sounds like you
>
>are getting the error before the creation transaction has committed.
>
>Randy
>
>  
>
>>-----Original Message-----
>>From: Vadim Nasardinov [mailto:vadimn at redhat.com] 
>>Sent: Friday, May 14, 2004 9:44 AM
>>To: srini; redhat-ccm-list at redhat.com
>>Subject: Re: [redhat-ccm-list] CCM - Transactions. Please Help!!
>>
>>On Friday 14 May 2004 10:35, srini wrote:
>> 
>>
>>    
>>
>>>The other transaction is opened from within a Thread. Would
>>>that make any difference?
>>>   
>>>
>>>      
>>>
>>What do you mean by that?
>>
>>IIRC, the way things are set up is that each thread gets its own
>>Session.  Barring possible rare edge cases, there is a one-to-one
>>mapping between threads and sessions.
>>
>>Regardless, if a domain object has been successfully saved, you
>>shouldn't be getting a DataObjectNotFoundException with the code
>>you've shown.
>>
>>It might be a good idea for you to share a little more details of your
>>exact setup and/or tell us about your attempts to debug this on your
>>own.  People on this list may get a clue from what you say or forget
>>to say.
>>
>>
>> 
>>
>>    
>>
>
>
>  
>