Sorry for the repost , does anyone out there have any feedback on
this one ?
thanks
On Wed, 10 Jul 2002, St�phane Verlet wrote:
>
> Hi folks
>
> Here is my set up , in the same application I use 2 different databases, I
> have 2 JDO
> objects, the db have different name , different JNDI conn pools, however I
> have
> the SAME O/R mapping for the 2 db.
> The goal is not to share date across the dbs , each db is used
> independently, according to
> the context of the application.
>
> For one of the classes , I am using a High/Low key generator , and I
> noticed that
> depending on the order the mappings are loaded , the key generator would
> use
> the sequence table in the wrong db.
>
> for example
> starting application
> open a transaction with db1
> creating object1 of type A
> commiting and closing db1
>
> open a transaction with db2
> creating object2 of type B
> commiting and closing db2
>
> object1 and object2 would be created correctly , EXCEPT that object2
> would have an id from the
> sequence table of db1. ( object2.id=object1.id+grab_size )
>
> Using the "EJB" set up, same-connection = true , everything works
> properly, however this is
> no very applicable for me as I need to have several threads , creating
> objects of the same type at the
> same time in the same db , I ended up with a deadlock , as I guess each
> thread was fighting to get the next id block.
>
>
> I thought taht , may be , castor had "global" key-generator registry and
> tried using different key-gen alias
> for the 2 db , unsucessful (I learn later , while digging into the source
> that , the key-gen registry
> is db specific)
>
> After putting some debug statement , in Castor , I realized that Castor
> was using the right
> key generator instance for each cases , however I realized it gave the
> wrong db connection
> to the key-gen class
> in other word the key-gen instance for the db2 was using a connection to
> db1
>
> After more digging around , I realized that the problem lied in the
> org.exolab.castor.jdo.engine.SQLEngine class , in particular the
> getSeparateConnection() method
> that called
>
> dr=DatabaseRegistry.getDatabaseRegistry(_clsDesc.getJavaClass()); (line
> 360 in the latest CVS)
>
> to find out what db to use to create a new separate conn for the key gen
> The DatabaseRegistry.getDatabaseRegistry(Class) , goes through all the db
> registries
> to find which db this class is from. Obviously this explains my problem,
> as in my case the class
> definition appears in the 2 different dbs
>
> I also noticed that method DatabaseRegistry.getDatabaseRegistry(Class) is
> only called from this
> place, it almost look like some ad hoc method ...
>
> My main question , is Castor capable to handle my settings ? or is it a
> bug ?
>
> I started working on fix (if it is a bug, that is )
> This is my first real attempt at working with Castor internals (I have
> been a daily user for the
> last 2 months), so my aproach may seem a little bit out of place
>
> The idea , is to pass the DataBase object to the SQLEngine so that when
> it needs to create a separate connection for id generation , it picks
> the right db by calling DatabaseRegistry.getDatabaseRegistry(String
> dbName)
> here are the steps
> adding the public String getDatabaseName() method to the the
> DataBase interface and DataBaseImpl class
> adding the Database getDatabase() method in the
> TransactionContext class
> in the ClassMolder , passing the the Database object from the
> TransactionContext when calling
> SQLEngine to create a new Object
> using that Database object information , to create the separate
> conn
>
> I ran a couple tests , and this fix my issue; However I am afraid that I
> cannot be sure if it breaks
> anything else , as I do not fully understand the Castor code base and I
> haven t had time
> to setup a full dev environment to run the full test suite.
>
> If indeed , this is considered a bug , and I don t see why castor should
> not be capable
> to connect to 2 different db , with the same schema in the same
> application ...
> I would be glad to provide my little fix as a patch , or provide another
> patch with a fix
> featuring a different (better) approach if someone can suggested such a
> thing.
>
> Thanks
>
> Stephane
>
> -----------------------------------------------------------
> If you wish to unsubscribe from this mailing, send mail to
> [EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
>
>
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
