Werner,

 

            Before we indulge into the time out issues, I would like your confirmation whether this is an expected behavior, wherein an object being dbLocked also gets the read lock on it.

 

If the output of the sample code below is as the expected behavior, I wouldn’t like to have read locks when I DbLock my object, since the performance of my application is degrading a lot.

 

            Regarding the table type, I’m using innodb tables of mysql.

 

Here’s the Log of my test case:

Setting data in DB

Setting data in DB -- Done

Starting Writer thread.....

WriterThread -- Before db locking

WriterThread -- After db locking

WriterThread -- Before updating name

ReaderThread -- Starting reader thread.....

ReaderThread -- Trying to read.....

WriterThread -- After updating name

WriterThread -- Commiting & Closing transaction

ReaderThread -- Read: [Rocket(WriterThread changed Name), with Fuel(Solid Ammonia)]

ReaderThread -- Trying to read.....

ReaderThread -- Read: [Rocket(WriterThread changed Name), with Fuel(Solid Ammonia)]

ReaderThread -- Trying to read.....

ReaderThread -- Read: [Rocket(WriterThread changed Name), with Fuel(Solid Ammonia)]

ReaderThread -- Trying to read.....

ReaderThread -- Read: [Rocket(WriterThread changed Name), with Fuel(Solid Ammonia)]

ReaderThread -- Trying to read.....

ReaderThread -- Read: [Rocket(WriterThread changed Name), with Fuel(Solid Ammonia)]

WriterThread -- Clearing the DB

ReaderThread -- Trying to read.....

ReaderThread -- Read: [Rocket(WriterThread changed Name), with Fuel(Solid Ammonia)]

WriterThread -- Clearing the DB... finished

ReaderThread -- Stopped reading.

 

The run method of Writer thread:

 

public void run()

    {

        try

        {

            System.out.println("Starting Writer thread.....");

 

            System.out.println("WriterThread -- Before db locking");

 

            Rocket rocket =

                rocket_DAO.retrieveByName(

                    PRITHVI, transaction, Transaction.DbLocked);

            System.out.println("WriterThread -- After db locking");

            System.out.println("WriterThread -- Before updating name");

            sleep(3000);

            rocket.setRocketName("WriterThread changed Name");

            System.out.println("WriterThread -- After updating name");

            sleep(10000);

            transaction.commitAndClose();

            System.out.println(

                "WriterThread -- Commiting & Closing transaction");

            sleep(5000);

            System.out.println("WriterThread -- Clearing the DB");

            deleteDB();

            System.out.println("WriterThread -- Clearing the DB... finished");

        }

        catch (Exception e)

        {

            e.printStackTrace();

        }

    }

 

The run method of the Writer Thread:

 

    public void run()

    {

        try

        {

            System.out.println("ReaderThread -- Starting reader thread.....");

 

            while (read)

            {

                System.out.println("ReaderThread -- Trying to read.....");

 

                ArrayList rockets =

                    rocket_DAO.retrieveAllRockets(txn, Transaction.ReadOnly);

                System.out.println("ReaderThread -- Read: " + rockets);

                sleep(1000);

            }

 

            System.out.println("ReaderThread -- Stopped reading.");

        }

        catch (Exception e)

        {

            e.printStackTrace();

        }

    }

 

 

Thanks & Regards,

Jimmy

-----Original Message-----
From: Werner Guttmann [mailto:[EMAIL PROTECTED]
Sent:
Wednesday, June 02, 2004 6:08 PM
To: [EMAIL PROTECTED]
Subject: Re: [castor-user] Dblocked mode & Mysql DB

 

Jimmy,

you could try increasing the lock timeout to a value that suits your needs via JDO.setLockTimeout (int) rather than messing around with read and write locks. Btw, what table type are you using with mySQL ?

In addition, can you please provide us with a complete stack tarce of the exception being thrown when a read operation's lock expires ?

Thanks
Werner

PleaseJDO.java--Original Message Text---
From: [EMAIL PROTECTED]
Date: Wed, 2 Jun 2004 17:02:33 +0530



Hi,



I working with Castor 0.9.5.3 (Cache type = NONE) & mySQL 4 and I am facing problems wherein castor says Read lock timeout, this usually occurs when I try to read an object in one thread, but at the same time some other thread has dblocked that object. I also happen to notice that, when I do a Dblock on an object, Castor applies both a read & write lock on the record, but mysql allows read on those records mapped to the object, at its prompt.



I guess the read lock timeouts are happening because the object thats been dbLocked, is been held in the lock state for more than the timeout period and the reading thread is not allowed access to this object. But this could be serious limitation, since in my application there many threads working on the same object/table and if a thread happen to dblocked that object for some period of time, then the remaining threads who just want to read has to wait, till the read lock is released.



So I would like to know is there any way that I could just do a write lock and not read lock on the object that I would like to update. Also does Castor have any specific way of retrieving objects referenced in an object; say in the order its been mapped in the mapping file or does Castor loads the object in an arbitrary fashion.





Thanks & Regards,

Jimmy Thomas




Confidentiality Notice

The information contained in this electronic message and any attachments to this message are intended
for the exclusive use of the addressee(s) and may contain confidential or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately
and destroy all copies of this message and any attachments.

Confidentiality Notice

The information contained in this electronic message and any attachments to this message are intended
for the exclusive use of the addressee(s) and may contain confidential or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately
and destroy all copies of this message and any attachments.
----------------------------------------------------------- 
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
        unsubscribe castor-user

Reply via email to