RE: Auto incremented primary key and extents
Armin Sorry for being thick -- I looked at the code again and understood and tested it! As an aside, is there a sequence generator that will be unique across multiple JVMs (and therefore OJB instances) accessing the database at the same time? Thanks Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 28 October 2003 20:08 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: Armin On this note, with batch mode set to false, I decided to look into sequences in OJB. I currently use the default hi low sequence. I have an extent where the top level class is an interface And some concrete classes about 2 further levels down e.g. TopLevelInterface + +-++ Interface1 Interface2 Interface3 + + +++---+ Impl1 Impl2 Impl3 Impl4 etc I often query things from the top level or one of the intermediate levels (Interface1 to 3 above). My question regarding sequences is that I have cleared out OJB_HL_SEQ as reocmmended in the documentation When changing repository/extents) and I notice that although the max ID for the extent with TopLevelInterface At the top is correct the sequence name appears to be Interface1. The first thing I did was save some instances of Impl1 and Impl2. Surely for this to work next time the VM starts I would have to have the sequence name of ToplevelInterface so that the IDs are unique across the entire extent (e.g. from ToplevelInterface down) The reason I say this is that if I start storing instances of Impl3 and 4 say, how will they get the right Sequence e.gf. Interface1 is not visible from Impl3 or 4 -- the only commonly visible interface is The top level one hence I would have expected the sequence to have this name. I hope you can (or someone can) shed some light on my confusion. doh! ;-) first, I don't know how your class-descriptors are defined. I will describe the best case scenario: Need sequence name for Impl3 autoincrement field Get TopLevel class for Impl3 -- TopLevelInterface Is TopLevelInterface is extent? -- then try to find first none null table name. Assume TopLevelInterface has extents Interface1, Interface2, Interface3 then OJB check all extents of Interface1,... for real class and its table name (search recursive the first none null table name - that's the reason for the note in the docs). The result for sequence name maybe SEQ_IMPL1_TABLE. Thus all real classes should get the same unique sequence name SEQ_IMPL1_TABLE. Why not use name of the top level class as sequence name? Assume you map the classes Fish and Mammal (no collective interface or base class) to one table. Then top level class name is equivalent to class names and you will end up with two different sequence names for the same table -- duplicate sequence keys. I will be happy if you find a better solution :-) By the way, if you don't trust the auto-generated sequence name for such complex mappings, declare a sequence name in the field-descriptor of your classes. regards, Armin Regards, Mark Rowell -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:50 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: Sorry After looking at SequenceManaherHelper I know that the max id of sequence for extent is not... More on the batch mode stuff -- I onlt just turned it on and got these problems. RC4 has been working Prior to setting batch-mode=true in the configuration. hmm, AFAIK Oleg has fixed some bugs in conjunction with batch mode (since rc4). So your problems maybe a side-effect of the bugs in batch-mode. regards, Armin -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:25 To: 'OJB Users List' Subject: RE: Auto incremented primary key and extents Armin No the only thing I changed was OJB.properties. One thing is that this problem happened during a run of my application where some batch mode=true stuff Was used. Would this have an impact? Is the sequence max id still stored in OJB_HL_SEQ? Regards Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:21 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, But as a follow on the extents are more than one level deep -- would this have an impact? No should not. Have a look in SequenceManagerHelper#getMaxForExtent unique Over all tables in the extent? Have I misconfigured OJB on upgrading to RC4? Did you change metadata on upgrading? Add new extents, change order of declaration? regards, Armin Mark Rowell wrote: Sorry But as a follow on the extents
Re: Auto incremented primary key and extents
Hi Mark, Mark Rowell wrote: Armin Sorry for being thick -- I looked at the code again and understood and tested it! As an aside, is there a sequence generator that will be unique across multiple JVMs (and therefore OJB instances) accessing the database at the same time? yep! - SequenceManagerNextValImpl (use database based sequences, calling 'nextval' command). Unique across different JVM and different apps using sequences too. - since SequenceManagerHighLowImpl use optimistic locking (= rc3) this sequence manager implementation should be unique across JVM. regards, Armin Thanks Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 28 October 2003 20:08 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: Armin On this note, with batch mode set to false, I decided to look into sequences in OJB. I currently use the default hi low sequence. I have an extent where the top level class is an interface And some concrete classes about 2 further levels down e.g. TopLevelInterface + +-++ Interface1 Interface2 Interface3 + + +++---+ Impl1 Impl2 Impl3 Impl4 etc I often query things from the top level or one of the intermediate levels (Interface1 to 3 above). My question regarding sequences is that I have cleared out OJB_HL_SEQ as reocmmended in the documentation When changing repository/extents) and I notice that although the max ID for the extent with TopLevelInterface At the top is correct the sequence name appears to be Interface1. The first thing I did was save some instances of Impl1 and Impl2. Surely for this to work next time the VM starts I would have to have the sequence name of ToplevelInterface so that the IDs are unique across the entire extent (e.g. from ToplevelInterface down) The reason I say this is that if I start storing instances of Impl3 and 4 say, how will they get the right Sequence e.gf. Interface1 is not visible from Impl3 or 4 -- the only commonly visible interface is The top level one hence I would have expected the sequence to have this name. I hope you can (or someone can) shed some light on my confusion. doh! ;-) first, I don't know how your class-descriptors are defined. I will describe the best case scenario: Need sequence name for Impl3 autoincrement field Get TopLevel class for Impl3 -- TopLevelInterface Is TopLevelInterface is extent? -- then try to find first none null table name. Assume TopLevelInterface has extents Interface1, Interface2, Interface3 then OJB check all extents of Interface1,... for real class and its table name (search recursive the first none null table name - that's the reason for the note in the docs). The result for sequence name maybe SEQ_IMPL1_TABLE. Thus all real classes should get the same unique sequence name SEQ_IMPL1_TABLE. Why not use name of the top level class as sequence name? Assume you map the classes Fish and Mammal (no collective interface or base class) to one table. Then top level class name is equivalent to class names and you will end up with two different sequence names for the same table -- duplicate sequence keys. I will be happy if you find a better solution :-) By the way, if you don't trust the auto-generated sequence name for such complex mappings, declare a sequence name in the field-descriptor of your classes. regards, Armin Regards, Mark Rowell -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:50 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: Sorry After looking at SequenceManaherHelper I know that the max id of sequence for extent is not... More on the batch mode stuff -- I onlt just turned it on and got these problems. RC4 has been working Prior to setting batch-mode=true in the configuration. hmm, AFAIK Oleg has fixed some bugs in conjunction with batch mode (since rc4). So your problems maybe a side-effect of the bugs in batch-mode. regards, Armin -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:25 To: 'OJB Users List' Subject: RE: Auto incremented primary key and extents Armin No the only thing I changed was OJB.properties. One thing is that this problem happened during a run of my application where some batch mode=true stuff Was used. Would this have an impact? Is the sequence max id still stored in OJB_HL_SEQ? Regards Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:21 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, But as a follow on the extents are more than one level deep -- would this have an impact? No should not. Have a look in SequenceManagerHelper
RE: Auto incremented primary key and extents
Armin Thanks -- to switch from Hi low to SequenceManagerNextValImpl/SequenceManagerHighLowImpl is there anything I should do to the OJB system tables etc apart from change OJB configuration accordingly? (apart from me doing the RTFM thing...) Cheers Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 29 October 2003 13:28 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: Armin Sorry for being thick -- I looked at the code again and understood and tested it! As an aside, is there a sequence generator that will be unique across multiple JVMs (and therefore OJB instances) accessing the database at the same time? yep! - SequenceManagerNextValImpl (use database based sequences, calling 'nextval' command). Unique across different JVM and different apps using sequences too. - since SequenceManagerHighLowImpl use optimistic locking (= rc3) this sequence manager implementation should be unique across JVM. regards, Armin Thanks Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 28 October 2003 20:08 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: Armin On this note, with batch mode set to false, I decided to look into sequences in OJB. I currently use the default hi low sequence. I have an extent where the top level class is an interface And some concrete classes about 2 further levels down e.g. TopLevelInterface + +-++ Interface1 Interface2 Interface3 + + +++---+ Impl1 Impl2 Impl3 Impl4 etc I often query things from the top level or one of the intermediate levels (Interface1 to 3 above). My question regarding sequences is that I have cleared out OJB_HL_SEQ as reocmmended in the documentation When changing repository/extents) and I notice that although the max ID for the extent with TopLevelInterface At the top is correct the sequence name appears to be Interface1. The first thing I did was save some instances of Impl1 and Impl2. Surely for this to work next time the VM starts I would have to have the sequence name of ToplevelInterface so that the IDs are unique across the entire extent (e.g. from ToplevelInterface down) The reason I say this is that if I start storing instances of Impl3 and 4 say, how will they get the right Sequence e.gf. Interface1 is not visible from Impl3 or 4 -- the only commonly visible interface is The top level one hence I would have expected the sequence to have this name. I hope you can (or someone can) shed some light on my confusion. doh! ;-) first, I don't know how your class-descriptors are defined. I will describe the best case scenario: Need sequence name for Impl3 autoincrement field Get TopLevel class for Impl3 -- TopLevelInterface Is TopLevelInterface is extent? -- then try to find first none null table name. Assume TopLevelInterface has extents Interface1, Interface2, Interface3 then OJB check all extents of Interface1,... for real class and its table name (search recursive the first none null table name - that's the reason for the note in the docs). The result for sequence name maybe SEQ_IMPL1_TABLE. Thus all real classes should get the same unique sequence name SEQ_IMPL1_TABLE. Why not use name of the top level class as sequence name? Assume you map the classes Fish and Mammal (no collective interface or base class) to one table. Then top level class name is equivalent to class names and you will end up with two different sequence names for the same table -- duplicate sequence keys. I will be happy if you find a better solution :-) By the way, if you don't trust the auto-generated sequence name for such complex mappings, declare a sequence name in the field-descriptor of your classes. regards, Armin Regards, Mark Rowell -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:50 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: Sorry After looking at SequenceManaherHelper I know that the max id of sequence for extent is not... More on the batch mode stuff -- I onlt just turned it on and got these problems. RC4 has been working Prior to setting batch-mode=true in the configuration. hmm, AFAIK Oleg has fixed some bugs in conjunction with batch mode (since rc4). So your problems maybe a side-effect of the bugs in batch-mode. regards, Armin -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:25 To: 'OJB Users List' Subject: RE: Auto incremented primary key and extents Armin No the only thing I changed was OJB.properties. One
RE: Auto incremented primary key and extents
Sorry -- I guess I am already using SequenceManagerHighLowImpl...(I should know this!).. So as it stands using RC4 I should be OK with multiple JVMs accessing the database using the HighLowImpl sequence manager. Thanks Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 29 October 2003 13:28 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: Armin Sorry for being thick -- I looked at the code again and understood and tested it! As an aside, is there a sequence generator that will be unique across multiple JVMs (and therefore OJB instances) accessing the database at the same time? yep! - SequenceManagerNextValImpl (use database based sequences, calling 'nextval' command). Unique across different JVM and different apps using sequences too. - since SequenceManagerHighLowImpl use optimistic locking (= rc3) this sequence manager implementation should be unique across JVM. regards, Armin Thanks Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 28 October 2003 20:08 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: Armin On this note, with batch mode set to false, I decided to look into sequences in OJB. I currently use the default hi low sequence. I have an extent where the top level class is an interface And some concrete classes about 2 further levels down e.g. TopLevelInterface + +-++ Interface1 Interface2 Interface3 + + +++---+ Impl1 Impl2 Impl3 Impl4 etc I often query things from the top level or one of the intermediate levels (Interface1 to 3 above). My question regarding sequences is that I have cleared out OJB_HL_SEQ as reocmmended in the documentation When changing repository/extents) and I notice that although the max ID for the extent with TopLevelInterface At the top is correct the sequence name appears to be Interface1. The first thing I did was save some instances of Impl1 and Impl2. Surely for this to work next time the VM starts I would have to have the sequence name of ToplevelInterface so that the IDs are unique across the entire extent (e.g. from ToplevelInterface down) The reason I say this is that if I start storing instances of Impl3 and 4 say, how will they get the right Sequence e.gf. Interface1 is not visible from Impl3 or 4 -- the only commonly visible interface is The top level one hence I would have expected the sequence to have this name. I hope you can (or someone can) shed some light on my confusion. doh! ;-) first, I don't know how your class-descriptors are defined. I will describe the best case scenario: Need sequence name for Impl3 autoincrement field Get TopLevel class for Impl3 -- TopLevelInterface Is TopLevelInterface is extent? -- then try to find first none null table name. Assume TopLevelInterface has extents Interface1, Interface2, Interface3 then OJB check all extents of Interface1,... for real class and its table name (search recursive the first none null table name - that's the reason for the note in the docs). The result for sequence name maybe SEQ_IMPL1_TABLE. Thus all real classes should get the same unique sequence name SEQ_IMPL1_TABLE. Why not use name of the top level class as sequence name? Assume you map the classes Fish and Mammal (no collective interface or base class) to one table. Then top level class name is equivalent to class names and you will end up with two different sequence names for the same table -- duplicate sequence keys. I will be happy if you find a better solution :-) By the way, if you don't trust the auto-generated sequence name for such complex mappings, declare a sequence name in the field-descriptor of your classes. regards, Armin Regards, Mark Rowell -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:50 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: Sorry After looking at SequenceManaherHelper I know that the max id of sequence for extent is not... More on the batch mode stuff -- I onlt just turned it on and got these problems. RC4 has been working Prior to setting batch-mode=true in the configuration. hmm, AFAIK Oleg has fixed some bugs in conjunction with batch mode (since rc4). So your problems maybe a side-effect of the bugs in batch-mode. regards, Armin -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:25 To: 'OJB Users List' Subject: RE: Auto incremented primary key and extents Armin No the only thing I changed was OJB.properties. One thing is that this problem happened
RE: Auto incremented primary key and extents
Hi Armin Just one more question, so looking at the FAQ, I should basically add a version (say private int ojbVersion) field to every class I want to store instanes of in the database and change the repository accordingly? Thanks Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 29 October 2003 14:40 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: To anyone on the list Can you tell me how the SequenvceManagerHighLowImpl guarantees uniqueness of autoincremented Id's across JVMs -- I cant work out how it does it from the code (across JVMs using OJB) it use optimistic locking. (http://db.apache.org/ojb/faq.html#How to set up Optimistic Locking) See SequenceManagerHighLowImpl#getSequence(...) method. If a new set of keys (e.g. next 20, from 221-240) was requested a HighLowSequence object was read from DB. This instance has a version number. If know another sequence manager instance (another thread or instance in different JVM) update the same HighLowSequence (same row in DB) the version number change. If we now try to store the requested HighLowSequence we will get an OptimisticLockingException. regards, Armin Thanks Mark Rowell -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED] Sent: 29 October 2003 13:38 To: 'OJB Users List' Subject: RE: Auto incremented primary key and extents Sorry -- I guess I am already using SequenceManagerHighLowImpl...(I should know this!).. So as it stands using RC4 I should be OK with multiple JVMs accessing the database using the HighLowImpl sequence manager. Thanks Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 29 October 2003 13:28 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: Armin Sorry for being thick -- I looked at the code again and understood and tested it! As an aside, is there a sequence generator that will be unique across multiple JVMs (and therefore OJB instances) accessing the database at the same time? yep! - SequenceManagerNextValImpl (use database based sequences, calling 'nextval' command). Unique across different JVM and different apps using sequences too. - since SequenceManagerHighLowImpl use optimistic locking (= rc3) this sequence manager implementation should be unique across JVM. regards, Armin Thanks Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 28 October 2003 20:08 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: Armin On this note, with batch mode set to false, I decided to look into sequences in OJB. I currently use the default hi low sequence. I have an extent where the top level class is an interface And some concrete classes about 2 further levels down e.g. TopLevelInterface + +-++ Interface1 Interface2 Interface3 + + +++---+ Impl1 Impl2 Impl3 Impl4 etc I often query things from the top level or one of the intermediate levels (Interface1 to 3 above). My question regarding sequences is that I have cleared out OJB_HL_SEQ as reocmmended in the documentation When changing repository/extents) and I notice that although the max ID for the extent with TopLevelInterface At the top is correct the sequence name appears to be Interface1. The first thing I did was save some instances of Impl1 and Impl2. Surely for this to work next time the VM starts I would have to have the sequence name of ToplevelInterface so that the IDs are unique across the entire extent (e.g. from ToplevelInterface down) The reason I say this is that if I start storing instances of Impl3 and 4 say, how will they get the right Sequence e.gf. Interface1 is not visible from Impl3 or 4 -- the only commonly visible interface is The top level one hence I would have expected the sequence to have this name. I hope you can (or someone can) shed some light on my confusion. doh! ;-) first, I don't know how your class-descriptors are defined. I will describe the best case scenario: Need sequence name for Impl3 autoincrement field Get TopLevel class for Impl3 -- TopLevelInterface Is TopLevelInterface is extent? -- then try to find first none null table name. Assume TopLevelInterface has extents Interface1, Interface2, Interface3 then OJB check all extents of Interface1,... for real class and its table name (search recursive the first none null table name - that's the reason for the note in the docs). The result for sequence name maybe SEQ_IMPL1_TABLE. Thus all real classes should get the same unique sequence name SEQ_IMPL1_TABLE. Why not use name of the top level class
Re: Auto incremented primary key and extents
Hi again, Mark Rowell wrote: Hi Armin Just one more question, so looking at the FAQ, I should basically add a version (say private int ojbVersion) field to every class I want to store instanes of in the database and change the repository accordingly? only to get unique id's across different JVMs? no (it's all managed by OJB). yes, if you want to use optimistic locking for all your objects (to avoid dealing with stale data and overwrite changes made by another thread/JVM). Maybe this will help you http://www.mail-archive.com/[EMAIL PROTECTED]/msg03792.html regards, Armin Thanks Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 29 October 2003 14:40 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: To anyone on the list Can you tell me how the SequenvceManagerHighLowImpl guarantees uniqueness of autoincremented Id's across JVMs -- I cant work out how it does it from the code (across JVMs using OJB) it use optimistic locking. (http://db.apache.org/ojb/faq.html#How to set up Optimistic Locking) See SequenceManagerHighLowImpl#getSequence(...) method. If a new set of keys (e.g. next 20, from 221-240) was requested a HighLowSequence object was read from DB. This instance has a version number. If know another sequence manager instance (another thread or instance in different JVM) update the same HighLowSequence (same row in DB) the version number change. If we now try to store the requested HighLowSequence we will get an OptimisticLockingException. regards, Armin Thanks Mark Rowell -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED] Sent: 29 October 2003 13:38 To: 'OJB Users List' Subject: RE: Auto incremented primary key and extents Sorry -- I guess I am already using SequenceManagerHighLowImpl...(I should know this!).. So as it stands using RC4 I should be OK with multiple JVMs accessing the database using the HighLowImpl sequence manager. Thanks Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 29 October 2003 13:28 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: Armin Sorry for being thick -- I looked at the code again and understood and tested it! As an aside, is there a sequence generator that will be unique across multiple JVMs (and therefore OJB instances) accessing the database at the same time? yep! - SequenceManagerNextValImpl (use database based sequences, calling 'nextval' command). Unique across different JVM and different apps using sequences too. - since SequenceManagerHighLowImpl use optimistic locking (= rc3) this sequence manager implementation should be unique across JVM. regards, Armin Thanks Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 28 October 2003 20:08 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: Armin On this note, with batch mode set to false, I decided to look into sequences in OJB. I currently use the default hi low sequence. I have an extent where the top level class is an interface And some concrete classes about 2 further levels down e.g. TopLevelInterface + +-++ Interface1 Interface2 Interface3 + + +++---+ Impl1 Impl2 Impl3 Impl4 etc I often query things from the top level or one of the intermediate levels (Interface1 to 3 above). My question regarding sequences is that I have cleared out OJB_HL_SEQ as reocmmended in the documentation When changing repository/extents) and I notice that although the max ID for the extent with TopLevelInterface At the top is correct the sequence name appears to be Interface1. The first thing I did was save some instances of Impl1 and Impl2. Surely for this to work next time the VM starts I would have to have the sequence name of ToplevelInterface so that the IDs are unique across the entire extent (e.g. from ToplevelInterface down) The reason I say this is that if I start storing instances of Impl3 and 4 say, how will they get the right Sequence e.gf. Interface1 is not visible from Impl3 or 4 -- the only commonly visible interface is The top level one hence I would have expected the sequence to have this name. I hope you can (or someone can) shed some light on my confusion. doh! ;-) first, I don't know how your class-descriptors are defined. I will describe the best case scenario: Need sequence name for Impl3 autoincrement field Get TopLevel class for Impl3 -- TopLevelInterface Is TopLevelInterface is extent? -- then try to find first none null table name. Assume TopLevelInterface has extents Interface1, Interface2, Interface3 then OJB check all extents of Interface1,... for real class and its
RE: Auto incremented primary key and extents
Thanks Armin Are there any unit tests that explicitly cover this (e.g. storing objects of same type in 2 threads)? I am trying to test this running two JVMs that both store new instances of the same type of object and I (think that I) see non uniqueness of IDs occasionally. E.g the test basically involves me Inserting 2 sets of objects into the database in a single JVM I get N rows stored in the database. When I clear down the table involved and run 2 JVMs to store one set of objects each I get a different total Number fo rows in the database. Perhaps I should come up with a small test setup which someone could run Independently to make sure I am not screwing up. Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 29 October 2003 15:40 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi again, Mark Rowell wrote: Hi Armin Just one more question, so looking at the FAQ, I should basically add a version (say private int ojbVersion) field to every class I want to store instanes of in the database and change the repository accordingly? only to get unique id's across different JVMs? no (it's all managed by OJB). yes, if you want to use optimistic locking for all your objects (to avoid dealing with stale data and overwrite changes made by another thread/JVM). Maybe this will help you http://www.mail-archive.com/[EMAIL PROTECTED]/msg03792.html regards, Armin Thanks Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 29 October 2003 14:40 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: To anyone on the list Can you tell me how the SequenvceManagerHighLowImpl guarantees uniqueness of autoincremented Id's across JVMs -- I cant work out how it does it from the code (across JVMs using OJB) it use optimistic locking. (http://db.apache.org/ojb/faq.html#How to set up Optimistic Locking) See SequenceManagerHighLowImpl#getSequence(...) method. If a new set of keys (e.g. next 20, from 221-240) was requested a HighLowSequence object was read from DB. This instance has a version number. If know another sequence manager instance (another thread or instance in different JVM) update the same HighLowSequence (same row in DB) the version number change. If we now try to store the requested HighLowSequence we will get an OptimisticLockingException. regards, Armin Thanks Mark Rowell -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED] Sent: 29 October 2003 13:38 To: 'OJB Users List' Subject: RE: Auto incremented primary key and extents Sorry -- I guess I am already using SequenceManagerHighLowImpl...(I should know this!).. So as it stands using RC4 I should be OK with multiple JVMs accessing the database using the HighLowImpl sequence manager. Thanks Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 29 October 2003 13:28 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: Armin Sorry for being thick -- I looked at the code again and understood and tested it! As an aside, is there a sequence generator that will be unique across multiple JVMs (and therefore OJB instances) accessing the database at the same time? yep! - SequenceManagerNextValImpl (use database based sequences, calling 'nextval' command). Unique across different JVM and different apps using sequences too. - since SequenceManagerHighLowImpl use optimistic locking (= rc3) this sequence manager implementation should be unique across JVM. regards, Armin Thanks Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 28 October 2003 20:08 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: Armin On this note, with batch mode set to false, I decided to look into sequences in OJB. I currently use the default hi low sequence. I have an extent where the top level class is an interface And some concrete classes about 2 further levels down e.g. TopLevelInterface + +-++ Interface1 Interface2 Interface3 + + +++---+ Impl1 Impl2 Impl3 Impl4 etc I often query things from the top level or one of the intermediate levels (Interface1 to 3 above). My question regarding sequences is that I have cleared out OJB_HL_SEQ as reocmmended in the documentation When changing repository/extents) and I notice that although the max ID for the extent with TopLevelInterface At the top is correct the sequence name appears to be Interface1. The first thing I did was save some instances of Impl1 and Impl2. Surely for this to work next time the VM starts I
Re: Auto incremented primary key and extents
Hi, please have a look in SMMultiThreadedTest. Think this is a good starting point for your attemps. Further on it shows how to use the JUnitExtension class to write multithreaded junit tests. Armin Mark Rowell wrote: Thanks Armin Are there any unit tests that explicitly cover this (e.g. storing objects of same type in 2 threads)? I am trying to test this running two JVMs that both store new instances of the same type of object and I (think that I) see non uniqueness of IDs occasionally. E.g the test basically involves me Inserting 2 sets of objects into the database in a single JVM I get N rows stored in the database. When I clear down the table involved and run 2 JVMs to store one set of objects each I get a different total Number fo rows in the database. Perhaps I should come up with a small test setup which someone could run Independently to make sure I am not screwing up. Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 29 October 2003 15:40 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi again, Mark Rowell wrote: Hi Armin Just one more question, so looking at the FAQ, I should basically add a version (say private int ojbVersion) field to every class I want to store instanes of in the database and change the repository accordingly? only to get unique id's across different JVMs? no (it's all managed by OJB). yes, if you want to use optimistic locking for all your objects (to avoid dealing with stale data and overwrite changes made by another thread/JVM). Maybe this will help you http://www.mail-archive.com/[EMAIL PROTECTED]/msg03792.html regards, Armin Thanks Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 29 October 2003 14:40 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: To anyone on the list Can you tell me how the SequenvceManagerHighLowImpl guarantees uniqueness of autoincremented Id's across JVMs -- I cant work out how it does it from the code (across JVMs using OJB) it use optimistic locking. (http://db.apache.org/ojb/faq.html#How to set up Optimistic Locking) See SequenceManagerHighLowImpl#getSequence(...) method. If a new set of keys (e.g. next 20, from 221-240) was requested a HighLowSequence object was read from DB. This instance has a version number. If know another sequence manager instance (another thread or instance in different JVM) update the same HighLowSequence (same row in DB) the version number change. If we now try to store the requested HighLowSequence we will get an OptimisticLockingException. regards, Armin Thanks Mark Rowell -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED] Sent: 29 October 2003 13:38 To: 'OJB Users List' Subject: RE: Auto incremented primary key and extents Sorry -- I guess I am already using SequenceManagerHighLowImpl...(I should know this!).. So as it stands using RC4 I should be OK with multiple JVMs accessing the database using the HighLowImpl sequence manager. Thanks Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 29 October 2003 13:28 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: Armin Sorry for being thick -- I looked at the code again and understood and tested it! As an aside, is there a sequence generator that will be unique across multiple JVMs (and therefore OJB instances) accessing the database at the same time? yep! - SequenceManagerNextValImpl (use database based sequences, calling 'nextval' command). Unique across different JVM and different apps using sequences too. - since SequenceManagerHighLowImpl use optimistic locking (= rc3) this sequence manager implementation should be unique across JVM. regards, Armin Thanks Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 28 October 2003 20:08 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: Armin On this note, with batch mode set to false, I decided to look into sequences in OJB. I currently use the default hi low sequence. I have an extent where the top level class is an interface And some concrete classes about 2 further levels down e.g. TopLevelInterface + +-++ Interface1 Interface2 Interface3 + + +++---+ Impl1 Impl2 Impl3 Impl4 etc I often query things from the top level or one of the intermediate levels (Interface1 to 3 above). My question regarding sequences is that I have cleared out OJB_HL_SEQ as reocmmended in the documentation When changing repository/extents) and I notice that although the max ID for the extent with TopLevelInterface At the top is correct the sequence
Re: Auto incremented primary key and extents
Mark Rowell wrote: Thanks Armin Are there any unit tests that explicitly cover this (e.g. storing objects of same type in 2 threads)? I am trying to test this running two JVMs that both store new instances of the same type of object and I (think that I) see non uniqueness of IDs occasionally. E.g the test basically involves me Inserting 2 sets of objects into the database in a single JVM I get N rows stored in the database. When I clear down the table involved and run 2 JVMs to store one set of objects each I get a different total Number fo rows in the database. This could be ok, because in some cases you can get an OptimisticLockingException and the object (using optimistic locking) was not stored. Armin Perhaps I should come up with a small test setup which someone could run Independently to make sure I am not screwing up. Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 29 October 2003 15:40 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi again, Mark Rowell wrote: Hi Armin Just one more question, so looking at the FAQ, I should basically add a version (say private int ojbVersion) field to every class I want to store instanes of in the database and change the repository accordingly? only to get unique id's across different JVMs? no (it's all managed by OJB). yes, if you want to use optimistic locking for all your objects (to avoid dealing with stale data and overwrite changes made by another thread/JVM). Maybe this will help you http://www.mail-archive.com/[EMAIL PROTECTED]/msg03792.html regards, Armin Thanks Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 29 October 2003 14:40 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: To anyone on the list Can you tell me how the SequenvceManagerHighLowImpl guarantees uniqueness of autoincremented Id's across JVMs -- I cant work out how it does it from the code (across JVMs using OJB) it use optimistic locking. (http://db.apache.org/ojb/faq.html#How to set up Optimistic Locking) See SequenceManagerHighLowImpl#getSequence(...) method. If a new set of keys (e.g. next 20, from 221-240) was requested a HighLowSequence object was read from DB. This instance has a version number. If know another sequence manager instance (another thread or instance in different JVM) update the same HighLowSequence (same row in DB) the version number change. If we now try to store the requested HighLowSequence we will get an OptimisticLockingException. regards, Armin Thanks Mark Rowell -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED] Sent: 29 October 2003 13:38 To: 'OJB Users List' Subject: RE: Auto incremented primary key and extents Sorry -- I guess I am already using SequenceManagerHighLowImpl...(I should know this!).. So as it stands using RC4 I should be OK with multiple JVMs accessing the database using the HighLowImpl sequence manager. Thanks Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 29 October 2003 13:28 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: Armin Sorry for being thick -- I looked at the code again and understood and tested it! As an aside, is there a sequence generator that will be unique across multiple JVMs (and therefore OJB instances) accessing the database at the same time? yep! - SequenceManagerNextValImpl (use database based sequences, calling 'nextval' command). Unique across different JVM and different apps using sequences too. - since SequenceManagerHighLowImpl use optimistic locking (= rc3) this sequence manager implementation should be unique across JVM. regards, Armin Thanks Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 28 October 2003 20:08 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: Armin On this note, with batch mode set to false, I decided to look into sequences in OJB. I currently use the default hi low sequence. I have an extent where the top level class is an interface And some concrete classes about 2 further levels down e.g. TopLevelInterface + +-++ Interface1 Interface2 Interface3 + + +++---+ Impl1 Impl2 Impl3 Impl4 etc I often query things from the top level or one of the intermediate levels (Interface1 to 3 above). My question regarding sequences is that I have cleared out OJB_HL_SEQ as reocmmended in the documentation When changing repository/extents) and I notice that although the max ID for the extent with TopLevelInterface At the top is correct the sequence name appears to be Interface1. The first thing I
RE: Auto incremented primary key and extents
autogenerated keys using the DefaultSequenceManagerImpl are not assigned on broker.store(obj) using batch-mode=true. I'm wondering if the hash gets messed up (ordering) on the batch. On Mon, 2003-10-27 at 05:25, Mark Rowell wrote: Armin No the only thing I changed was OJB.properties. One thing is that this problem happened during a run of my application where some batch mode=true stuff Was used. Would this have an impact? Is the sequence max id still stored in OJB_HL_SEQ? Regards Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:21 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, But as a follow on the extents are more than one level deep -- would this have an impact? No should not. Have a look in SequenceManagerHelper#getMaxForExtent unique Over all tables in the extent? Have I misconfigured OJB on upgrading to RC4? Did you change metadata on upgrading? Add new extents, change order of declaration? regards, Armin Mark Rowell wrote: Sorry But as a follow on the extents are more than one level deep -- would this have an impact? Regards, Mark Rowell -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 11:30 To: '[EMAIL PROTECTED]' Subject: Auto incremented primary key and extents Hi I have an extent over 8 classes (and 8 corresponding tables) and I have noticed that primary keys are now not unique over all tables -- e.g. when I store and instances of 2 different classes In different leaves of the extent I get the same ID in both tables. In RC1 I the autogenerated IDs were unique Over all tables in the extent? Have I misconfigured OJB on upgrading to RC4? Regards, Mark Rowell --- Mark Rowell Structured Credit Europe CreditTrade Limited 180 Fleet Street London EC4A 2HG Tel +44 (0)20 7400 5078 Fax +44 (0)20 7400 5099 http://www.credittrade.com CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All rights reserved. The information and data contained in this email is provided for the information purposes of the addressee only and should not be reproduced and/or distributed to any other person. It is provided without any warranty whatsoever and unless stated otherwise consists purely of indicative market prices and other information. Any opinion or comments expressed or assumption made in association with the data or information provided in this email is a reflection of CreditTrades judgement at the time of compiling the data and is subject to change. CreditTrade hereby makes no representation and accepts no responsibility or liability as to the completeness or accuracy of this email. The content of this email is not intended as an offer or solicitation for, or recommendation of, the purchase or sale of any financial instrument, or as an official confirmation of any transaction, and should not be construed as investment advice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All rights reserved. The information and data contained in this email is provided for the information purposes of the addressee only and should not be reproduced and/or distributed to any other person. It is provided without any warranty whatsoever and unless stated otherwise consists purely of indicative market prices and other information. Any opinion or comments expressed or assumption made in association with the data or information provided in this email is a reflection of CreditTrades judgement at the time of compiling the data and is subject to change. CreditTrade hereby makes no representation and accepts no responsibility or liability as to the completeness or accuracy of this email. The content of this email is not intended as an offer or solicitation for, or recommendation of, the purchase or sale of any financial instrument, or as an official confirmation of any transaction, and should not be construed as investment advice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All rights reserved. The information and data contained in this email is provided for the information purposes of the addressee only and should
RE: Auto incremented primary key and extents
Thanks Andy I have set batch mode to false just to be on the safe side...i have used batch mode on earlier versions of OJB and not had any problems as far as I could tell... ;-) Cheers, Mark -Original Message- From: Andy Czerwonka [mailto:[EMAIL PROTECTED] Sent: 28 October 2003 15:05 To: OJB Users List Subject: RE: Auto incremented primary key and extents autogenerated keys using the DefaultSequenceManagerImpl are not assigned on broker.store(obj) using batch-mode=true. I'm wondering if the hash gets messed up (ordering) on the batch. On Mon, 2003-10-27 at 05:25, Mark Rowell wrote: Armin No the only thing I changed was OJB.properties. One thing is that this problem happened during a run of my application where some batch mode=true stuff Was used. Would this have an impact? Is the sequence max id still stored in OJB_HL_SEQ? Regards Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:21 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, But as a follow on the extents are more than one level deep -- would this have an impact? No should not. Have a look in SequenceManagerHelper#getMaxForExtent unique Over all tables in the extent? Have I misconfigured OJB on upgrading to RC4? Did you change metadata on upgrading? Add new extents, change order of declaration? regards, Armin Mark Rowell wrote: Sorry But as a follow on the extents are more than one level deep -- would this have an impact? Regards, Mark Rowell -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 11:30 To: '[EMAIL PROTECTED]' Subject: Auto incremented primary key and extents Hi I have an extent over 8 classes (and 8 corresponding tables) and I have noticed that primary keys are now not unique over all tables -- e.g. when I store and instances of 2 different classes In different leaves of the extent I get the same ID in both tables. In RC1 I the autogenerated IDs were unique Over all tables in the extent? Have I misconfigured OJB on upgrading to RC4? Regards, Mark Rowell --- Mark Rowell Structured Credit Europe CreditTrade Limited 180 Fleet Street London EC4A 2HG Tel +44 (0)20 7400 5078 Fax +44 (0)20 7400 5099 http://www.credittrade.com CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All rights reserved. The information and data contained in this email is provided for the information purposes of the addressee only and should not be reproduced and/or distributed to any other person. It is provided without any warranty whatsoever and unless stated otherwise consists purely of indicative market prices and other information. Any opinion or comments expressed or assumption made in association with the data or information provided in this email is a reflection of CreditTrades judgement at the time of compiling the data and is subject to change. CreditTrade hereby makes no representation and accepts no responsibility or liability as to the completeness or accuracy of this email. The content of this email is not intended as an offer or solicitation for, or recommendation of, the purchase or sale of any financial instrument, or as an official confirmation of any transaction, and should not be construed as investment advice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All rights reserved. The information and data contained in this email is provided for the information purposes of the addressee only and should not be reproduced and/or distributed to any other person. It is provided without any warranty whatsoever and unless stated otherwise consists purely of indicative market prices and other information. Any opinion or comments expressed or assumption made in association with the data or information provided in this email is a reflection of CreditTrades judgement at the time of compiling the data and is subject to change. CreditTrade hereby makes no representation and accepts no responsibility or liability as to the completeness or accuracy of this email. The content of this email is not intended as an offer or solicitation for, or recommendation of, the purchase or sale of any financial instrument, or as an official confirmation of any transaction, and should not be construed as investment advice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
RE: Auto incremented primary key and extents
Armin On this note, with batch mode set to false, I decided to look into sequences in OJB. I currently use the default hi low sequence. I have an extent where the top level class is an interface And some concrete classes about 2 further levels down e.g. TopLevelInterface + +-++ Interface1 Interface2 Interface3 + + +++---+ Impl1 Impl2 Impl3 Impl4 etc I often query things from the top level or one of the intermediate levels (Interface1 to 3 above). My question regarding sequences is that I have cleared out OJB_HL_SEQ as reocmmended in the documentation When changing repository/extents) and I notice that although the max ID for the extent with TopLevelInterface At the top is correct the sequence name appears to be Interface1. The first thing I did was save some instances of Impl1 and Impl2. Surely for this to work next time the VM starts I would have to have the sequence name of ToplevelInterface so that the IDs are unique across the entire extent (e.g. from ToplevelInterface down) The reason I say this is that if I start storing instances of Impl3 and 4 say, how will they get the right Sequence e.gf. Interface1 is not visible from Impl3 or 4 -- the only commonly visible interface is The top level one hence I would have expected the sequence to have this name. I hope you can (or someone can) shed some light on my confusion. Regards, Mark Rowell -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:50 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: Sorry After looking at SequenceManaherHelper I know that the max id of sequence for extent is not... More on the batch mode stuff -- I onlt just turned it on and got these problems. RC4 has been working Prior to setting batch-mode=true in the configuration. hmm, AFAIK Oleg has fixed some bugs in conjunction with batch mode (since rc4). So your problems maybe a side-effect of the bugs in batch-mode. regards, Armin -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:25 To: 'OJB Users List' Subject: RE: Auto incremented primary key and extents Armin No the only thing I changed was OJB.properties. One thing is that this problem happened during a run of my application where some batch mode=true stuff Was used. Would this have an impact? Is the sequence max id still stored in OJB_HL_SEQ? Regards Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:21 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, But as a follow on the extents are more than one level deep -- would this have an impact? No should not. Have a look in SequenceManagerHelper#getMaxForExtent unique Over all tables in the extent? Have I misconfigured OJB on upgrading to RC4? Did you change metadata on upgrading? Add new extents, change order of declaration? regards, Armin Mark Rowell wrote: Sorry But as a follow on the extents are more than one level deep -- would this have an impact? Regards, Mark Rowell -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 11:30 To: '[EMAIL PROTECTED]' Subject: Auto incremented primary key and extents Hi I have an extent over 8 classes (and 8 corresponding tables) and I have noticed that primary keys are now not unique over all tables -- e.g. when I store and instances of 2 different classes In different leaves of the extent I get the same ID in both tables. In RC1 I the autogenerated IDs were unique Over all tables in the extent? Have I misconfigured OJB on upgrading to RC4? Regards, Mark Rowell --- Mark Rowell Structured Credit Europe CreditTrade Limited 180 Fleet Street London EC4A 2HG Tel +44 (0)20 7400 5078 Fax +44 (0)20 7400 5099 http://www.credittrade.com CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All rights reserved. The information and data contained in this email is provided for the information purposes of the addressee only and should not be reproduced and/or distributed to any other person. It is provided without any warranty whatsoever and unless stated otherwise consists purely of indicative market prices and other information. Any opinion or comments expressed or assumption made in association with the data or information provided in this email is a reflection of CreditTrades judgement at the time of compiling the data and is subject to change. CreditTrade hereby makes no representation and accepts no responsibility or liability as to the completeness or accuracy of this email
Re: Auto incremented primary key and extents
Hi Mark, But as a follow on the extents are more than one level deep -- would this have an impact? No should not. Have a look in SequenceManagerHelper#getMaxForExtent unique Over all tables in the extent? Have I misconfigured OJB on upgrading to RC4? Did you change metadata on upgrading? Add new extents, change order of declaration? regards, Armin Mark Rowell wrote: Sorry But as a follow on the extents are more than one level deep -- would this have an impact? Regards, Mark Rowell -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 11:30 To: '[EMAIL PROTECTED]' Subject: Auto incremented primary key and extents Hi I have an extent over 8 classes (and 8 corresponding tables) and I have noticed that primary keys are now not unique over all tables -- e.g. when I store and instances of 2 different classes In different leaves of the extent I get the same ID in both tables. In RC1 I the autogenerated IDs were unique Over all tables in the extent? Have I misconfigured OJB on upgrading to RC4? Regards, Mark Rowell --- Mark Rowell Structured Credit Europe CreditTrade Limited 180 Fleet Street London EC4A 2HG Tel +44 (0)20 7400 5078 Fax +44 (0)20 7400 5099 http://www.credittrade.com CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All rights reserved. The information and data contained in this email is provided for the information purposes of the addressee only and should not be reproduced and/or distributed to any other person. It is provided without any warranty whatsoever and unless stated otherwise consists purely of indicative market prices and other information. Any opinion or comments expressed or assumption made in association with the data or information provided in this email is a reflection of CreditTrades judgement at the time of compiling the data and is subject to change. CreditTrade hereby makes no representation and accepts no responsibility or liability as to the completeness or accuracy of this email. The content of this email is not intended as an offer or solicitation for, or recommendation of, the purchase or sale of any financial instrument, or as an official confirmation of any transaction, and should not be construed as investment advice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All rights reserved. The information and data contained in this email is provided for the information purposes of the addressee only and should not be reproduced and/or distributed to any other person. It is provided without any warranty whatsoever and unless stated otherwise consists purely of indicative market prices and other information. Any opinion or comments expressed or assumption made in association with the data or information provided in this email is a reflection of CreditTrades judgement at the time of compiling the data and is subject to change. CreditTrade hereby makes no representation and accepts no responsibility or liability as to the completeness or accuracy of this email. The content of this email is not intended as an offer or solicitation for, or recommendation of, the purchase or sale of any financial instrument, or as an official confirmation of any transaction, and should not be construed as investment advice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Auto incremented primary key and extents
Sorry After looking at SequenceManaherHelper I know that the max id of sequence for extent is not... More on the batch mode stuff -- I onlt just turned it on and got these problems. RC4 has been working Prior to setting batch-mode=true in the configuration. -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:25 To: 'OJB Users List' Subject: RE: Auto incremented primary key and extents Armin No the only thing I changed was OJB.properties. One thing is that this problem happened during a run of my application where some batch mode=true stuff Was used. Would this have an impact? Is the sequence max id still stored in OJB_HL_SEQ? Regards Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:21 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, But as a follow on the extents are more than one level deep -- would this have an impact? No should not. Have a look in SequenceManagerHelper#getMaxForExtent unique Over all tables in the extent? Have I misconfigured OJB on upgrading to RC4? Did you change metadata on upgrading? Add new extents, change order of declaration? regards, Armin Mark Rowell wrote: Sorry But as a follow on the extents are more than one level deep -- would this have an impact? Regards, Mark Rowell -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 11:30 To: '[EMAIL PROTECTED]' Subject: Auto incremented primary key and extents Hi I have an extent over 8 classes (and 8 corresponding tables) and I have noticed that primary keys are now not unique over all tables -- e.g. when I store and instances of 2 different classes In different leaves of the extent I get the same ID in both tables. In RC1 I the autogenerated IDs were unique Over all tables in the extent? Have I misconfigured OJB on upgrading to RC4? Regards, Mark Rowell --- Mark Rowell Structured Credit Europe CreditTrade Limited 180 Fleet Street London EC4A 2HG Tel +44 (0)20 7400 5078 Fax +44 (0)20 7400 5099 http://www.credittrade.com CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All rights reserved. The information and data contained in this email is provided for the information purposes of the addressee only and should not be reproduced and/or distributed to any other person. It is provided without any warranty whatsoever and unless stated otherwise consists purely of indicative market prices and other information. Any opinion or comments expressed or assumption made in association with the data or information provided in this email is a reflection of CreditTrades judgement at the time of compiling the data and is subject to change. CreditTrade hereby makes no representation and accepts no responsibility or liability as to the completeness or accuracy of this email. The content of this email is not intended as an offer or solicitation for, or recommendation of, the purchase or sale of any financial instrument, or as an official confirmation of any transaction, and should not be construed as investment advice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All rights reserved. The information and data contained in this email is provided for the information purposes of the addressee only and should not be reproduced and/or distributed to any other person. It is provided without any warranty whatsoever and unless stated otherwise consists purely of indicative market prices and other information. Any opinion or comments expressed or assumption made in association with the data or information provided in this email is a reflection of CreditTrades judgement at the time of compiling the data and is subject to change. CreditTrade hereby makes no representation and accepts no responsibility or liability as to the completeness or accuracy of this email. The content of this email is not intended as an offer or solicitation for, or recommendation of, the purchase or sale of any financial instrument, or as an official confirmation of any transaction, and should not be construed as investment advice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All rights reserved. The information and data contained in this email is provided
Re: Auto incremented primary key and extents
Hi Mark, Mark Rowell wrote: Sorry After looking at SequenceManaherHelper I know that the max id of sequence for extent is not... More on the batch mode stuff -- I onlt just turned it on and got these problems. RC4 has been working Prior to setting batch-mode=true in the configuration. hmm, AFAIK Oleg has fixed some bugs in conjunction with batch mode (since rc4). So your problems maybe a side-effect of the bugs in batch-mode. regards, Armin -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:25 To: 'OJB Users List' Subject: RE: Auto incremented primary key and extents Armin No the only thing I changed was OJB.properties. One thing is that this problem happened during a run of my application where some batch mode=true stuff Was used. Would this have an impact? Is the sequence max id still stored in OJB_HL_SEQ? Regards Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:21 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, But as a follow on the extents are more than one level deep -- would this have an impact? No should not. Have a look in SequenceManagerHelper#getMaxForExtent unique Over all tables in the extent? Have I misconfigured OJB on upgrading to RC4? Did you change metadata on upgrading? Add new extents, change order of declaration? regards, Armin Mark Rowell wrote: Sorry But as a follow on the extents are more than one level deep -- would this have an impact? Regards, Mark Rowell -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 11:30 To: '[EMAIL PROTECTED]' Subject: Auto incremented primary key and extents Hi I have an extent over 8 classes (and 8 corresponding tables) and I have noticed that primary keys are now not unique over all tables -- e.g. when I store and instances of 2 different classes In different leaves of the extent I get the same ID in both tables. In RC1 I the autogenerated IDs were unique Over all tables in the extent? Have I misconfigured OJB on upgrading to RC4? Regards, Mark Rowell --- Mark Rowell Structured Credit Europe CreditTrade Limited 180 Fleet Street London EC4A 2HG Tel +44 (0)20 7400 5078 Fax +44 (0)20 7400 5099 http://www.credittrade.com CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All rights reserved. The information and data contained in this email is provided for the information purposes of the addressee only and should not be reproduced and/or distributed to any other person. It is provided without any warranty whatsoever and unless stated otherwise consists purely of indicative market prices and other information. Any opinion or comments expressed or assumption made in association with the data or information provided in this email is a reflection of CreditTrades judgement at the time of compiling the data and is subject to change. CreditTrade hereby makes no representation and accepts no responsibility or liability as to the completeness or accuracy of this email. The content of this email is not intended as an offer or solicitation for, or recommendation of, the purchase or sale of any financial instrument, or as an official confirmation of any transaction, and should not be construed as investment advice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All rights reserved. The information and data contained in this email is provided for the information purposes of the addressee only and should not be reproduced and/or distributed to any other person. It is provided without any warranty whatsoever and unless stated otherwise consists purely of indicative market prices and other information. Any opinion or comments expressed or assumption made in association with the data or information provided in this email is a reflection of CreditTrades judgement at the time of compiling the data and is subject to change. CreditTrade hereby makes no representation and accepts no responsibility or liability as to the completeness or accuracy of this email. The content of this email is not intended as an offer or solicitation for, or recommendation of, the purchase or sale of any financial instrument, or as an official confirmation of any transaction, and should not be construed as investment advice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All rights
RE: Auto incremented primary key and extents
Armin Thanks -- don't suppose you could grab me a CVS head could you if you get the chance... Thanks Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:50 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: Sorry After looking at SequenceManaherHelper I know that the max id of sequence for extent is not... More on the batch mode stuff -- I onlt just turned it on and got these problems. RC4 has been working Prior to setting batch-mode=true in the configuration. hmm, AFAIK Oleg has fixed some bugs in conjunction with batch mode (since rc4). So your problems maybe a side-effect of the bugs in batch-mode. regards, Armin -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:25 To: 'OJB Users List' Subject: RE: Auto incremented primary key and extents Armin No the only thing I changed was OJB.properties. One thing is that this problem happened during a run of my application where some batch mode=true stuff Was used. Would this have an impact? Is the sequence max id still stored in OJB_HL_SEQ? Regards Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:21 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, But as a follow on the extents are more than one level deep -- would this have an impact? No should not. Have a look in SequenceManagerHelper#getMaxForExtent unique Over all tables in the extent? Have I misconfigured OJB on upgrading to RC4? Did you change metadata on upgrading? Add new extents, change order of declaration? regards, Armin Mark Rowell wrote: Sorry But as a follow on the extents are more than one level deep -- would this have an impact? Regards, Mark Rowell -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 11:30 To: '[EMAIL PROTECTED]' Subject: Auto incremented primary key and extents Hi I have an extent over 8 classes (and 8 corresponding tables) and I have noticed that primary keys are now not unique over all tables -- e.g. when I store and instances of 2 different classes In different leaves of the extent I get the same ID in both tables. In RC1 I the autogenerated IDs were unique Over all tables in the extent? Have I misconfigured OJB on upgrading to RC4? Regards, Mark Rowell --- Mark Rowell Structured Credit Europe CreditTrade Limited 180 Fleet Street London EC4A 2HG Tel +44 (0)20 7400 5078 Fax +44 (0)20 7400 5099 http://www.credittrade.com CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All rights reserved. The information and data contained in this email is provided for the information purposes of the addressee only and should not be reproduced and/or distributed to any other person. It is provided without any warranty whatsoever and unless stated otherwise consists purely of indicative market prices and other information. Any opinion or comments expressed or assumption made in association with the data or information provided in this email is a reflection of CreditTrades judgement at the time of compiling the data and is subject to change. CreditTrade hereby makes no representation and accepts no responsibility or liability as to the completeness or accuracy of this email. The content of this email is not intended as an offer or solicitation for, or recommendation of, the purchase or sale of any financial instrument, or as an official confirmation of any transaction, and should not be construed as investment advice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All rights reserved. The information and data contained in this email is provided for the information purposes of the addressee only and should not be reproduced and/or distributed to any other person. It is provided without any warranty whatsoever and unless stated otherwise consists purely of indicative market prices and other information. Any opinion or comments expressed or assumption made in association with the data or information provided in this email is a reflection of CreditTrades judgement at the time of compiling the data and is subject to change. CreditTrade hereby makes no representation and accepts no responsibility or liability as to the completeness or accuracy of this email. The content of this email is not intended as an offer or solicitation for, or recommendation of, the purchase or sale of any financial instrument, or as an official confirmation of any transaction, and should not be construed as investment advice
