Re: Locking granularity
Set auto-update=none in the child's reference to the parent, if I understand you correctly. Pulat Laran Evans wrote: My meta-question is "Is verioning configurable with respect to object locking?" That said, here's my scenario. I have a parent Object and child objects. When I change a child (a Collection owned by the parent instance) and call store() on the parent, the version number of the parent changes. When I change the parent the parent version number changes (as one would expect). Is it possible to configure OJB such that a change to the child increments the version number of the child but not the parent? Thanks. - 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: OJB documentation
Perhaps, native German speakers created the documentation, and I appreciate their effort. If anything needs to be improved, anyone is free to submit patches for peer review or file a feature or bug request. Pulat Bobby Lawrence wrote: Whats up with all the German (or whatever foreign language) found everywhere in the documentation? Ex: http://db.apache.org/ojb/docu/guides/advanced-technique.html#Nested+Objects Reference the class-descriptor XML example and take a look at the table names Not that the table names are important, its just weird. --Bobby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Vulnerabilities
I'd like to thank everyone for your valuable input. Season's greetings! Pulat Pulat Yunusov wrote: Is there a list of OJB security vulnerabilities: current and closed? Is this information regularly collected or posted and where, in this list? Thank you, Pulat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Vulnerabilities
Is there a list of OJB security vulnerabilities: current and closed? Is this information regularly collected or posted and where, in this list? Thank you, Pulat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PB Tutorial: Query By Criteria on Object
Your "template" likely refers to an instance with the default value for
the primary key field, which is 0, and there is no record with PK equal
to zero in your database.
Pulat
Annapoorani Rathi wrote:
Hi,
I just started on OJB..
In PB Tutorial, the code snippet does not fetch me the record and result is null (though the record is present in DB)
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
QueryByCriteria query = new QueryByCriteria(template);
result = (Product)broker.getObjectByQuery(query);
But if i replace the above with the code below, i do get a populated result object
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
Criteria criteria = new Criteria();
criteria.addEqualTo("name","Sprocket");
QueryByCriteria query = new QueryByCriteria(Product.class, criteria);
result = (Product)broker.getObjectByQuery(query);
I understand that the first Impl decodes to Second internally.
But then the first Impl does not work.
Can anyone help me to reason out??
Thanks
Anna
-
Yahoo! Messenger - Communicate instantly..."Ping" your friends today!
Download Messenger Now
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using alternate key instead of primary key when relating an class descriptor with a collection descriptor
I don't think what you want is possible because it goes against concepts
of row indentity and referential integrity.
A foreign key in one table implies a relation to the primary key in the
other table, and there can be only one primary key.
The normal way to specify the relationship you want is to add a user id
attribute to the UserRole class and use the inverse-foreignkey attribute
in the user roles' collection descriptor.
Pulat
Sean Dockery wrote:
Hello.
I've searched the gmane archives, but I was unable to find any messages
related to my question.
Suppose that I have the following classes...
public class User {
private Integer id; // primary key field
private String username; // alternate key field
private Collection userRoles; // collection of UserRole objects related
by username
};
public class UserRole {
private String username; // foreign key
private String rolename;
}
...and I wanted to relate User and UserRole in a repository mapping based
on the equality of the username fields in both User and UserRole. Can this
exact schema be handled through a repository mapping? (Does
fk-pointing-to-this-class work without using an indirection-table? Is
there an alternative?)
Most of the rest of the data model in the application uses User.id as a
foreign key, so we can't easily change the primary key of the user table.
The UserRole fields were chosen for compatibility with Tomcat
JDBCRealm-like declarative security implementations.
The only way that I can see to work around this problem is to duplicate the
User.id field in the UserRole table, along with the username.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJB doesnt work with multiples context
What is a "context"? Francisco Bruno wrote: OJB doesn't work simultaneously with some contexts? [], Francisco Bruno - "Faça as coisas o mais simples que você puder, porém não as mais simples." Albert Einstein - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FW: Newbie Question : There was no default-PBKey specified
Can you please modify your mailer so it doesn't request return receipts? Thank you, Pulat Stark, Roman wrote: For the past tow days I tried to set up the ojb-blank project. Everything I try ends up with the following message: "There was no default-PBKey specified" I am using eclips 3 for the project following the instructions from the web site. All I have tried so far is just get a connection and run a very simple QueryByCriteria. I did set up the repository.xml files, of which there are 3 plus repository.xml. The database xml has a simple I really am at a loss, any suggestions would be great on this. I don't even know where to look anymore for what set up could cause this problem. Thanks Roman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HighLowSequenceManager chaos
I use ObjectCachePerBrokerImpl and I don't have the problems you described. Pulat Daniel Perry wrote: My repository_internal.xml didnt have the ObjectCacheEmptyImpl cache set up for the hl_seq class, so it would have been using the ObjectCacheDefaultImpl. Could this have caused the problem? I need to work out what went wrong, as it cannot happen again (very unhappy clients!!!) Daniel. -Original Message- From: Daniel Perry [mailto:[EMAIL PROTECTED] Sent: 18 October 2004 15:43 To: OJB Users List Subject: RE: HighLowSequenceManager chaos Duh, cant use native - it's not extent-aware :( So, highlow seems to be working when i start it. But it seemed ok before (until it started overwriting data): it wrote 1 to 83, then 123 to 140, then 101 to 132 (at which point the overwriting was noticed!!! ie 123-132 had been done twice!). Could it be anything to do with caching of the HighLowSequence object? Daniel. -Original Message- From: Daniel Perry [mailto:[EMAIL PROTECTED] Sent: 18 October 2004 15:27 To: OJB Users List Subject: RE: HighLowSequenceManager chaos Ok, so it is working for some reason when i was using an older version of ojb and hsqldb it was going up in jumps of the grabsize, so i just assumed that was what it did! Anyway, the real problem i've had is that it has been going incremental up to a certain point in time, then it jumped about 50 places forward, then went incremental for a week or so and then jumped back and started overwriting existing objects, which obviously isnt good. I've decided to convert to letting mysql do the incrementing, and tell ojb to use native impl. Daniel. -Original Message- From: Pulat Yunusov [mailto:[EMAIL PROTECTED] Sent: 18 October 2004 15:19 To: OJB Users List Subject: Re: HighLowSequenceManager chaos Grab size refers to the number of consecutive values from which the sequence manager issues primary keys until it reaches a value equal to the max_key - 1. Then the max_key is increased by the grab size, and the sequence manager continues to issue primary keys until it exhausts the sequence again. Pulat Daniel Perry wrote: Hi, I've been trying to debug some problems in our software, and it seems that the High Low Sequence Manager has gone a bit mad! I am seeing some wierd stuff going on - the sequence manager has NO settings, so should be acting in the default configuration. The OJB_HL_SEQ is showing grabsizes of 20, and multiples of 20 in the max column, but it doesnt seem to be using them. eg, i initialise the app and in OJB_HL_SEQ i see: SEQ_pdp,deprecatedColumn,160,209 But when i insert data, i get id's of 161,162,163. I would expect 180,200,220. When i go to the HL_SEQ table after shutting down the app, i see that the MAX_KEY is only 180. I've turned on debugging and i see messages like the following, which look right to me, except that it comes up with the same message each time - it should be incremented right? [org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl] DEBUG: new sequence was [EMAIL PROTECTED] ame=SEQ_pd p,fieldName=deprecatedColumn,grabSize=20,version=9,maxKey=180,curr entKey=160 ] Anyone seen this kind of problem before? Daniel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HighLowSequenceManager chaos
The next value in sequence will be bumped up to the max key value, when the SequenceManager class is reloaded (when the JVM is restarted, for example). The high low sequence manager works well for me, and I didn't observe the irregular behavior you described. Pulat Daniel Perry wrote: Ok, so it is working for some reason when i was using an older version of ojb and hsqldb it was going up in jumps of the grabsize, so i just assumed that was what it did! Anyway, the real problem i've had is that it has been going incremental up to a certain point in time, then it jumped about 50 places forward, then went incremental for a week or so and then jumped back and started overwriting existing objects, which obviously isnt good. I've decided to convert to letting mysql do the incrementing, and tell ojb to use native impl. Daniel. -Original Message----- From: Pulat Yunusov [mailto:[EMAIL PROTECTED] Sent: 18 October 2004 15:19 To: OJB Users List Subject: Re: HighLowSequenceManager chaos Grab size refers to the number of consecutive values from which the sequence manager issues primary keys until it reaches a value equal to the max_key - 1. Then the max_key is increased by the grab size, and the sequence manager continues to issue primary keys until it exhausts the sequence again. Pulat Daniel Perry wrote: Hi, I've been trying to debug some problems in our software, and it seems that the High Low Sequence Manager has gone a bit mad! I am seeing some wierd stuff going on - the sequence manager has NO settings, so should be acting in the default configuration. The OJB_HL_SEQ is showing grabsizes of 20, and multiples of 20 in the max column, but it doesnt seem to be using them. eg, i initialise the app and in OJB_HL_SEQ i see: SEQ_pdp,deprecatedColumn,160,209 But when i insert data, i get id's of 161,162,163. I would expect 180,200,220. When i go to the HL_SEQ table after shutting down the app, i see that the MAX_KEY is only 180. I've turned on debugging and i see messages like the following, which look right to me, except that it comes up with the same message each time - it should be incremented right? [org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl] DEBUG: new sequence was [EMAIL PROTECTED] ame=SEQ_pd p,fieldName=deprecatedColumn,grabSize=20,version=9,maxKey=180,curr entKey=160 ] Anyone seen this kind of problem before? Daniel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HighLowSequenceManager chaos
Grab size refers to the number of consecutive values from which the sequence manager issues primary keys until it reaches a value equal to the max_key - 1. Then the max_key is increased by the grab size, and the sequence manager continues to issue primary keys until it exhausts the sequence again. Pulat Daniel Perry wrote: Hi, I've been trying to debug some problems in our software, and it seems that the High Low Sequence Manager has gone a bit mad! I am seeing some wierd stuff going on - the sequence manager has NO settings, so should be acting in the default configuration. The OJB_HL_SEQ is showing grabsizes of 20, and multiples of 20 in the max column, but it doesnt seem to be using them. eg, i initialise the app and in OJB_HL_SEQ i see: SEQ_pdp,deprecatedColumn,160,209 But when i insert data, i get id's of 161,162,163. I would expect 180,200,220. When i go to the HL_SEQ table after shutting down the app, i see that the MAX_KEY is only 180. I've turned on debugging and i see messages like the following, which look right to me, except that it comes up with the same message each time - it should be incremented right? [org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl] DEBUG: new sequence was [EMAIL PROTECTED] p,fieldName=deprecatedColumn,grabSize=20,version=9,maxKey=180,currentKey=160 ] Anyone seen this kind of problem before? Daniel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Metadata listeners
We add and remove descriptor and connection repositories during our application lifecycle using MetadataManager. It seems useful and logical to have listener interfaces for DescriptorRepository and ConnectionRepository because some objects need to cleanup their state when the metadata is removed. For example, a sequence manager might want to discard a transient part of sequences for a jcd that's just been unloaded - just like it happens when the sequence manager is garbage collected. Do you think it's a good idea to add metadata listeners to the OJB API? Pulat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SequenceManager's integrity
Thank you, Armin. I am testing it now. Pulat Armin Waibel wrote: Hi, fixed in CVS (OJB 1.0.x branch OJB_1_0_RELEASE) Armin Armin Waibel wrote: Hi Pulat, Pulat Yunusov wrote: Currently, all PersistenceBrokers that use SequenceManagerHighLowImpl share one Map for keeping sequences. That map keys sequences essentially by table name in many common cases. I understand if two databases have tables with the same name, accessing them within a single OJB instance will lead to corruption of the sequence manager's internal map as one entry can potentially be replaced with another with the same key (same table name). yep, if two databases have tables with the same name and PK columns (more exactly, columns declared as autoincrement in repository) have the same name too. Is this a valid and a known problem and are you aware of any workarounds? you are right this could be an issue. I will fix this by using a static map with the jcdAlias name (defined in repository, have to be unique for each jdbc-connection-descriptor) as key and then per jcdAlias a map keeping the sequences by sequence name. regards, Armin Thank you, Pulat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SequenceManager's integrity
Currently, all PersistenceBrokers that use SequenceManagerHighLowImpl share one Map for keeping sequences. That map keys sequences essentially by table name in many common cases. I understand if two databases have tables with the same name, accessing them within a single OJB instance will lead to corruption of the sequence manager's internal map as one entry can potentially be replaced with another with the same key (same table name). Is this a valid and a known problem and are you aware of any workarounds? Thank you, Pulat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More than one sequence manage is possible in single connection repository ?
Instantiate the SequenceManager class you're interested in and set any parameters it may need directly via its set methods. Beware that such sequence managers as HighLowImpl and InMemoryImpl maintain sequences in static members rather than in instance state so you'll have to distinguish sequences by setting sequence names manually. Different sequence managers instances will still refer to the same sequence data in this case. Pulat Rajadurai K wrote: hi, i have a situation where i need to use more than one sequence manager. first one for all the tables what i m going to use. second one is i want to maintain only sequence no for some purpose. i m not going to use this for tables. but i want next values how i can do that pl. if anyone give me the solution it will be helpfull for me. thanks in advance. regards, Rajadurai - 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: Version and optimistic locking
No problem, Armin. :)
Pulat
Armin Waibel wrote:
Pulat Yunusov wrote:
Great, Armin. Are you committing this to CVS any time soon?
Thanks,
Done! It's in CVS now (both 1.1 trunk and 1.0.x branch - OJB_1_0_RELEASE).
Thanks for bag this bug ;-)
Armin
Pulat
Armin Waibel wrote:
> In statement 3 above, valueOf() will return false when updateLock
parsed
> from XML is null. Examining RepositoryXmlHandler's debug logs
indicates
> that null is indeed assigned to updateLock when the parsed
attribute is
> missing.
doh! I think you got it!
We should only set the updateLock field when parsed String is not null.
String updateLock = atts.getValue(tags.getTagById(UPDATE_LOCK));
if (isDebug) logger.debug(" " +
tags.getTagById(UPDATE_LOCK) + ": " + updateLock);
if(checkString(updateLock))
{
b = (Boolean.valueOf(updateLock)).booleanValue();
m_CurrentFLD.setUpdateLock(b);
}
This should fix the bug.
regards
Armin
Pulat Yunusov wrote:
Thanks for your reply, Armin.
Using a debugger I found that RepositoryXmlHandler sets updateLock
to false when "update-lock" is not specified.
Here is how it assigns a value to the updateLock attribute of the
current field descriptor object in RepositoryXmlHandler#startElement():
String updateLock = atts.getValue(tags.getTagById(UPDATE_LOCK));
if (isDebug) logger.debug(" " + tags.getTagById(UPDATE_LOCK) +
": " + updateLock);
b = (Boolean.valueOf(updateLock)).booleanValue();
m_CurrentFLD.setUpdateLock(b);
In statement 3 above, valueOf() will return false when updateLock
parsed from XML is null. Examining RepositoryXmlHandler's debug logs
indicates that null is indeed assigned to updateLock when the parsed
attribute is missing.
Statement 4 above will set updateLock in the field descriptor to
false when "update-lock" is missing in the mapping file, and reverse
the initial value of true for "updateLock" in the FieldDescriptor
class.
What's your take on this?
Thanks,
Pulat
Armin Waibel wrote:
Hi Pulat,
I checked the initialization value for 'updateLock' in
FieldDescriptor class and it's 'true'. So if you don't specify a
value the xml-parser should return 'true' or if this attribute was
skipped the initial value (true) should be used in FieldDescriptor.
In OJB test-suite are several locking tests
(OptimisticLockingTest.java) and all tests pass.
Maybe it's a parser/repository.dtd problem. You can enable OJB
parsing result when change log-level for class
RepositoryXmlHandler.java to 'debug'.
When using OJB default logger simply change entry for this class to
'debug' in OJB-logging.properties
regards,
Armin
Pulat Yunusov wrote:
I found that update-lock is false by default, that is when I don't
specify it in the locking field descriptor. When I set this
attribute to true explicitly, OJB increments the version field for
every insert and update.
I inspected the class-descriptor object passed to storeToDb() in
PersistenceBrokerImpl#store() with a debugger, and its
m_lockingFieldDescriptors attribute contained a FieldDescriptor
object with the value of updateLock attribute equal to false.
However, update-lock was not specified for that locking field in
the class-descriptor in my mapping file.
According to the DTD at
http://db.apache.org/ojb/repository.dtd.txt, the default value of
update-lock is true. I am using OJB 1.0.0. Have I found a bug, and
has anybody else experienced this?
Thanks,
Pulat
Pulat Yunusov wrote:
According to the OJB FAQ the version column "is incremented each
time changes are committed to the object". The version column is
the column described in field-descriptors with the "locking"
attribute set to true.
However, I have never ever seen values in this column other than
the default of zero. I assume this value should constantly grow
with every update to the record but I have never seen that happen.
What is wrong?
Thank you,
Pulat
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version and optimistic locking
Great, Armin. Are you committing this to CVS any time soon?
Thanks,
Pulat
Armin Waibel wrote:
> In statement 3 above, valueOf() will return false when updateLock parsed
> from XML is null. Examining RepositoryXmlHandler's debug logs indicates
> that null is indeed assigned to updateLock when the parsed attribute is
> missing.
doh! I think you got it!
We should only set the updateLock field when parsed String is not null.
String updateLock = atts.getValue(tags.getTagById(UPDATE_LOCK));
if (isDebug) logger.debug(" " +
tags.getTagById(UPDATE_LOCK) + ": " + updateLock);
if(checkString(updateLock))
{
b = (Boolean.valueOf(updateLock)).booleanValue();
m_CurrentFLD.setUpdateLock(b);
}
This should fix the bug.
regards
Armin
Pulat Yunusov wrote:
Thanks for your reply, Armin.
Using a debugger I found that RepositoryXmlHandler sets updateLock to
false when "update-lock" is not specified.
Here is how it assigns a value to the updateLock attribute of the
current field descriptor object in RepositoryXmlHandler#startElement():
String updateLock = atts.getValue(tags.getTagById(UPDATE_LOCK));
if (isDebug) logger.debug(" " + tags.getTagById(UPDATE_LOCK) + ":
" + updateLock);
b = (Boolean.valueOf(updateLock)).booleanValue();
m_CurrentFLD.setUpdateLock(b);
In statement 3 above, valueOf() will return false when updateLock
parsed from XML is null. Examining RepositoryXmlHandler's debug logs
indicates that null is indeed assigned to updateLock when the parsed
attribute is missing.
Statement 4 above will set updateLock in the field descriptor to false
when "update-lock" is missing in the mapping file, and reverse the
initial value of true for "updateLock" in the FieldDescriptor class.
What's your take on this?
Thanks,
Pulat
Armin Waibel wrote:
Hi Pulat,
I checked the initialization value for 'updateLock' in
FieldDescriptor class and it's 'true'. So if you don't specify a
value the xml-parser should return 'true' or if this attribute was
skipped the initial value (true) should be used in FieldDescriptor.
In OJB test-suite are several locking tests
(OptimisticLockingTest.java) and all tests pass.
Maybe it's a parser/repository.dtd problem. You can enable OJB
parsing result when change log-level for class
RepositoryXmlHandler.java to 'debug'.
When using OJB default logger simply change entry for this class to
'debug' in OJB-logging.properties
regards,
Armin
Pulat Yunusov wrote:
I found that update-lock is false by default, that is when I don't
specify it in the locking field descriptor. When I set this
attribute to true explicitly, OJB increments the version field for
every insert and update.
I inspected the class-descriptor object passed to storeToDb() in
PersistenceBrokerImpl#store() with a debugger, and its
m_lockingFieldDescriptors attribute contained a FieldDescriptor
object with the value of updateLock attribute equal to false.
However, update-lock was not specified for that locking field in the
class-descriptor in my mapping file.
According to the DTD at http://db.apache.org/ojb/repository.dtd.txt,
the default value of update-lock is true. I am using OJB 1.0.0. Have
I found a bug, and has anybody else experienced this?
Thanks,
Pulat
Pulat Yunusov wrote:
According to the OJB FAQ the version column "is incremented each
time changes are committed to the object". The version column is
the column described in field-descriptors with the "locking"
attribute set to true.
However, I have never ever seen values in this column other than
the default of zero. I assume this value should constantly grow
with every update to the record but I have never seen that happen.
What is wrong?
Thank you,
Pulat
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version and optimistic locking
Thanks for your reply, Armin.
Using a debugger I found that RepositoryXmlHandler sets updateLock to
false when "update-lock" is not specified.
Here is how it assigns a value to the updateLock attribute of the
current field descriptor object in RepositoryXmlHandler#startElement():
String updateLock = atts.getValue(tags.getTagById(UPDATE_LOCK));
if (isDebug) logger.debug(" " + tags.getTagById(UPDATE_LOCK) + ": "
+ updateLock);
b = (Boolean.valueOf(updateLock)).booleanValue();
m_CurrentFLD.setUpdateLock(b);
In statement 3 above, valueOf() will return false when updateLock parsed
from XML is null. Examining RepositoryXmlHandler's debug logs indicates
that null is indeed assigned to updateLock when the parsed attribute is
missing.
Statement 4 above will set updateLock in the field descriptor to false
when "update-lock" is missing in the mapping file, and reverse the
initial value of true for "updateLock" in the FieldDescriptor class.
What's your take on this?
Thanks,
Pulat
Armin Waibel wrote:
Hi Pulat,
I checked the initialization value for 'updateLock' in FieldDescriptor
class and it's 'true'. So if you don't specify a value the xml-parser
should return 'true' or if this attribute was skipped the initial value
(true) should be used in FieldDescriptor.
In OJB test-suite are several locking tests (OptimisticLockingTest.java)
and all tests pass.
Maybe it's a parser/repository.dtd problem. You can enable OJB parsing
result when change log-level for class RepositoryXmlHandler.java to
'debug'.
When using OJB default logger simply change entry for this class to
'debug' in OJB-logging.properties
regards,
Armin
Pulat Yunusov wrote:
I found that update-lock is false by default, that is when I don't
specify it in the locking field descriptor. When I set this attribute
to true explicitly, OJB increments the version field for every insert
and update.
I inspected the class-descriptor object passed to storeToDb() in
PersistenceBrokerImpl#store() with a debugger, and its
m_lockingFieldDescriptors attribute contained a FieldDescriptor object
with the value of updateLock attribute equal to false. However,
update-lock was not specified for that locking field in the
class-descriptor in my mapping file.
According to the DTD at http://db.apache.org/ojb/repository.dtd.txt,
the default value of update-lock is true. I am using OJB 1.0.0. Have I
found a bug, and has anybody else experienced this?
Thanks,
Pulat
Pulat Yunusov wrote:
According to the OJB FAQ the version column "is incremented each time
changes are committed to the object". The version column is the
column described in field-descriptors with the "locking" attribute
set to true.
However, I have never ever seen values in this column other than the
default of zero. I assume this value should constantly grow with
every update to the record but I have never seen that happen.
What is wrong?
Thank you,
Pulat
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version and optimistic locking
I found that update-lock is false by default, that is when I don't specify it in the locking field descriptor. When I set this attribute to true explicitly, OJB increments the version field for every insert and update. I inspected the class-descriptor object passed to storeToDb() in PersistenceBrokerImpl#store() with a debugger, and its m_lockingFieldDescriptors attribute contained a FieldDescriptor object with the value of updateLock attribute equal to false. However, update-lock was not specified for that locking field in the class-descriptor in my mapping file. According to the DTD at http://db.apache.org/ojb/repository.dtd.txt, the default value of update-lock is true. I am using OJB 1.0.0. Have I found a bug, and has anybody else experienced this? Thanks, Pulat Pulat Yunusov wrote: According to the OJB FAQ the version column "is incremented each time changes are committed to the object". The version column is the column described in field-descriptors with the "locking" attribute set to true. However, I have never ever seen values in this column other than the default of zero. I assume this value should constantly grow with every update to the record but I have never seen that happen. What is wrong? Thank you, Pulat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Optimistic Locking exception with 1.0 - doesn't happen with rc4
Kollivakkam,
Is the value in your MOD_NUM incremented properly every time the record
is updated? I am asking because I have a problem using the version field
for optimistic locking.
Thanks,
Pulat
Kollivakkam R. Raghavan wrote:
No our application is one where client and server need to periodically
sync. Up. Instead of using time to figure out what has changed we use a
synchronization seq. number which the client and server exchange. So
this is not the locking col. The locking column is the MOD_NUM column
in the table.
Thanks
Raghavan
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 16, 2004 12:34 AM
To: OJB Users List
Subject: Re: Optimistic Locking exception with 1.0 - doesn't happen with
rc4
Hi Raghavan,
do you increment the optimistic locking field by yourself with
policy.setSyncSeqNum(SynchronizationLogic.getNextSynchronizationSequence
Number().longValue());
??Armin
OJB itself does increment/reset the locking field, if you increment too,
all the time a OLException will be thrown.
regards
Kollivakkam R. Raghavan wrote:
Yes! Happens all the time. My repository file is attached. I am
using an integer version counter and set it up to have OJB provide the
value. It happens, when I'm trying to execute the following code. The
table declaration and the repository file are also attached. As you
can see it's pretty vanilla OJB code - nothing fancy.
---
private static void savePolicyRecord(AbstractConfigPolicyData policy,
AMCContext context) throws AMCException
{
PersistenceBroker broker = null;
if (context != null && context.getUser() != null) {
policy.setModifierId(context.getUser().getId());
}
policy.setModificationTime(new Date());
policy.setSyncSeqNum(SynchronizationLogic.getNextSynchronizationSequen
ce
Number().longValue());
try
{
broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
broker.beginTransaction();
broker.store(policy);
broker.commitTransaction();
}
catch(PBFactoryException ex)
{
log.error(PB_FACTORY_EXCEPTION, ex);
throw new AMCException(DATABASE_ERROR_KEY, ex,
DATABASE_ERROR_CODE);
}
catch(PersistenceBrokerException ex)
{
log.error(PERSISTENCE_BROKER_EXCEPTION, ex);
throw new AMCException(DATABASE_ERROR_KEY, ex,
DATABASE_ERROR_CODE);
}
finally
{
if (broker != null)
{
broker.close();
}
}
}
-
Table definition
CREATE TABLE AMC_NODE_PSET
(
IDint not null identity primary
key,
MODIFICATION_TIME timestamp default 'now' not null,
MODIFIER_ID int,
MOD_NUM int not null,
CREATED timestamp default 'now' not null,
NODE_ID int,
DR_ID int,
GOLDEN_CONFIG_ID int,
POLICY_TYPE varchar(4) not null,
BUNDLE_TYPE int default '1' not null, --
'1'
- ama, '2' - aons
CONFIG_STATE charnot null, -- 'G' - Golden
Config, 'A' - Add, 'M' - Modified, 'D' - Delete, 'R' - Archived.
SYNC_SEQ_NUM bigint not null,
DATA image,
NAME varchar(64) not null,
QNAME varchar(64) not null,
DESCRIPTION varchar(64),
EXT1 image,
EXT2 varchar(64),
EXT3 varchar(64),
foreign key(NODE_ID) references AMC_AONS_NODE(ID),
foreign key(DR_ID) references AMC_NODE_DR(ID),
foreign key(MODIFIER_ID) references AMC_USER(ID)
);
-Original Message-
From: Brian McCallister [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 14, 2004 6:14 PM
To: OJB Users List
Subject: Re: Optimistic Locking exception with 1.0 - doesn't happen
with
rc4
I presume you can reliably replicate it, can you provide more
information about when it is happening?
Database, mapping for the optimistic TX field etc?
There were a couple changes to optimistic tx's when using a timestamp
instead of version counter.
Any chance you can send a unit test which causes this to happen? If
not, enough information on exactly when it happens so that I can do so
would be appreciated!
-Brian
On Sep 14, 2004, at 8:03 PM, Kollivakkam R. Raghavan wrote:
I am getting the following exception with an optimistic locking which
does not happen with rc4. Did something change? We are about to use
OJB in production and I wanted to switch to the release version.
Please
help.
Thanks Raghavan
--
at java.lang.Thread.run(Unknown Source)
Caused by: org.apache.ojb.broker.OptimisticLockException: Object has
been modifi ed by someone else
at
org.apache.ojb.broker.accesslayer.JdbcAccessImpl.execute
Version and optimistic locking
According to the OJB FAQ the version column "is incremented each time changes are committed to the object". The version column is the column described in field-descriptors with the "locking" attribute set to true. However, I have never ever seen values in this column other than the default of zero. I assume this value should constantly grow with every update to the record but I have never seen that happen. What is wrong? Thank you, Pulat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJB and debug options
Logging levels are set in the OJB.properties files. Find a line that
specifies the logging level for your implementation of SQL generator,
e.g.
org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=WARN,
and put the appropriate value in ("DEBUG").
Around that part of the file, you can find lines setting logging levels
for other OJB components.
Pulat
Ajitesh Das wrote:
Hi list:
How and what to turn on for ojb debug options, so that I can debug the
SQLs, generated from the OJB queries.
I am using : MSSQL and jtds driver.
Thanks
--
A good friend will come bail you out of jail...but, a true friend will
be sitting next to you saying, "Damn...that was fun."
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Anonymous keys
Thank you, Brian. Your reply was very helpful. Pulat Brian McCallister wrote: Anonymous keys allow you to not have the FK field (or PK if you never need serialize them) defined on the classes. By default OJB talks directly to fields, not through property accessors (though it certainly can work through property accessors). -Brian On Sep 13, 2004, at 6:53 PM, Pulat Yunusov wrote: What is the purpose of anonymous keys? Given class A and class B where class A has a reference to class B, I removed setId() from both classes, and setBId() and getBId() from class A. I still have private members id in both classes, and bId in class A as well as all corresponding field and reference descritors in the mapping file. I have not set access to any of the fields as "anonymous" in the mapping file. Following that, I have no problem creating instances and setting a reference between them, persisting them or retrieving them. I thought you needed anonymous keys for that kind of behavior but I didn't use them. Can OJB access private instance variables to keep track of relationships? What exactly are anonymous keys for? Thank you, Pulat - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Anonymous keys
What is the purpose of anonymous keys? Given class A and class B where class A has a reference to class B, I removed setId() from both classes, and setBId() and getBId() from class A. I still have private members id in both classes, and bId in class A as well as all corresponding field and reference descritors in the mapping file. I have not set access to any of the fields as "anonymous" in the mapping file. Following that, I have no problem creating instances and setting a reference between them, persisting them or retrieving them. I thought you needed anonymous keys for that kind of behavior but I didn't use them. Can OJB access private instance variables to keep track of relationships? What exactly are anonymous keys for? Thank you, Pulat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
