Re: Queries for M:N collections?
Hi all, i found my bug ! it is in my p6spy library (a bug in the log module, this bug is referenced in bugzilla) Remi - Original Message - From: Rémi Bars [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, October 27, 2003 5:10 PM Subject: Queries for M:N collections? Hi all, i m trying to store an object A wich have a list of A element, when i try that it works first time and after i got this exception org.apache.ojb.broker.PersistenceBrokerException: java.lang.StringIndexOutOfBoundsException: String index out of range: -2 at org.apache.ojb.broker.core.PersistenceBrokerImpl.getMtoNImplementor(Persiste nceBrokerImpl.java:921) at org.apache.ojb.broker.core.PersistenceBrokerImpl.storeCollections(Persistenc eBrokerImpl.java:783) at org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(PersistenceBroker Impl.java:2007) t org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl .java:1889) at org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl .java:1851) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(Unknown Source) at org.apache.ojb.odmg.states.StateOldDirty.commit(Unknown Source) at org.apache.ojb.odmg.ObjectEnvelopeTable.commitAllEnvelopes(Unknown Source) at org.apache.ojb.odmg.ObjectEnvelopeTable.commit(Unknown Source) at org.apache.ojb.odmg.TransactionImpl.doCommitOnObjects(Unknown Source) at org.apache.ojb.odmg.TransactionImpl.prepare(Unknown Source) at org.apache.ojb.odmg.TransactionImpl.commit(Unknown Source) create table A(id int primary key not null) create table A_A(ParentID int not null, ID int not null,primary key (ParentID , ID)) class-descriptor class='A' table='A' field-descriptor name=id column=id jdbc-type=INTEGER primarykey=true autoincrement=true / collection-descriptor name=listOfA element-class-ref=A auto-retrieve=true auto-update=true auto-delete=false indirection-table=A_A fk-pointing-to-this-class column=ParentID/ fk-pointing-to-element-class column=ID / /collection-descriptor /class-descriptor - 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: Custom SequenceManager
In OQL Queries strings must be escaped: String id = \7f653507-0a28-0c51-0153-e0c0206f7a20\; Thomas -Original Message- From: Robert J Celestino [mailto:[EMAIL PROTECTED] Sent: Monday, October 27, 2003 10:20 PM To: OJB Users List Subject: Custom SequenceManager Hello, I am new to OJB and in the process of evaluating it for use on our project. So far I am very impressed and looking forward to using it in production. To that end, I have written my own sequence manager. It appears to work (records are created correctly with GUIDs correctly generated). But the Guids that we generate have imbedded dashes and that seems to cause the queries a problem. A very simple example: String id = 7f653507-0a28-0c51-0153-e0c0206f7a20 ; oqlQuery = select p from + Person.class.getName() + where Id = + id ; OQLQuery query = _omdg.newOQLQuery(); query.create( oqlQuery ) ; -- throws exception here : org.odmg.QueryInvalidException: expecting '', found '0' at org.apache.ojb.odmg.oql.OQLQueryImpl.create(Unknown Source) at org.apache.ojb.odmg.oql.OQLQueryImpl.create(Unknown Source) . . . Should I escape the string in some fashion? Escape the dashes? Does - signify something in particular? Any help greatly appreciated! Thanks, Bob c Bob Celestino SAS Research and Development 919 - 531 - 9425 [EMAIL PROTECTED] SAS - The Power to Know - 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: problems with batch-mode=true
Hi,
My questions are:
1) Which way should I use? start transaction first or set
batch mode to true first?
Both possibilities of declaration should work. I add a
test to reproduce your examples. With current CVS this test
was passed.
2) How do I know it really does batch delete?
hmm, with p6spy in 'normal' mode you see all delete
statements. In batch-mode you don't see any delete
statements for the deleted objects.
To really see what's going on you should use tools/logging
of your database.
3) Is there any disadvantage if I always set it to batch mode for any
transaction?
If you only insert/delete/update a single object (or a few objects)
batch mode may perform slower than without (Same when you insert
many different objects within the same tx).
regards,
Armin
Zhe Liu wrote:
RE: problems with batch-mode=trueSeems it works for me when I tried
following
1) batch-mode=true in repository
2) start transaction before setting the batch mode
broker.beginTransaction();
broker.serviceConnectionManager().setBatchMode(true);
3) I tried this on delete. There were no exceptions and the records got
deleted. However, it did not show me any delete statement in the log even
though I set the logging to debug mode.
4) If I switch the above to the following
broker.serviceConnectionManager().setBatchMode(true);
broker.beginTransaction();
I got following exception
org.apache.ojb.broker.TransactionInProgressException: ConnectionManager
is already in transaction
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.beginTransaction(Unknown
Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.beginTransaction(Unkn
own Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.beginTransaction(Unkn
own Source)
at
com.gsnx.ojbeval.db.GSNPersistenceBroker.delete(GSNPersistenceBroker.java:84
)
at com.gsnx.ojbeval.db.BaseDao.delete(BaseDao.java:57)
In the log, I did see the delete statement.
My questions are:
1) Which way should I use? start transaction first or set batch mode to
true first?
2) How do I know it really does batch delete?
3) Is there any disadvantage if I always set it to batch mode for any
transaction?
Thanks,
Zhe
-Original Message-
From: Bonnie MacKellar [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 22, 2003 6:02 AM
To: OJB Users List
Subject: RE: problems with batch-mode=true
Hi,
Here is the code that I tested. You can
see that setBatchMode is called before I start
the tx.
try
{
broker.serviceConnectionManager().setBatchMode(true);
broker.beginTransaction();
for (int i = 0; i 100; i++)
{
CustomerInterface customer = new Customer();
customer.setCustomerNumber(100 + i);
customer.setFirstName(Big);
customer.setLastName(Customer);
customer.setCustomerName(BadCorporation);
customer.setDeleteTag(Boolean.FALSE);
broker.store(customer);
}
// conMan.executeBatch();
broker.commitTransaction();
}
catch(Exception e)
{
e.printStackTrace();
logger.error(e.getMessage());
broker.abortTransaction();
}
finally
{
broker.close();
}
This chunk of code, exectued with batch-mode=true
in repository_database.xml, results in the following
two exceptions :
java.lang.IllegalArgumentException: object is not an instance of declaring
class
at java.lang.reflect.Method.invoke(Native Method)
at
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.doExecut
e(Unknown Source)
at
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.invoke(U
nknown Source)
at $Proxy0.doExecute(Unknown Source)
at
org.apache.ojb.broker.util.batch.BatchConnection.executeBatch(Unknown
Source)
at org.apache.ojb.broker.util.batch.BatchConnection.commit(Unknown
Source)
at
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.localCommit(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.commitTransaction(Unknown
Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction(Unk
nown Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction(Unk
nown Source)
at
com.mobius.activebill.dbmigrationutils.CustomerMigration.main(CustomerMigrat
ion.java:69)
3425 ERROR [main] dbmigrationutils.CustomerMigration - object is not an
instance of declaring class
3435 DEBUG [main] core.PersistenceBrokerImpl - PB.close was called:
[EMAIL PROTECTED]
org.apache.ojb.broker.TransactionNotInProgressException: ConnectionManager
is NOT in transaction
at
Re: OJB weblogic problem - No record found
Hi, Alen Tan wrote: Hi, I have this problem with OJB in weblogic. I have already set up the OJB to run in weblogic 7.1. There is a startup class to load the OJB up and bind to the JNDI tree. I store my application in the domain/applications directory. Everytime I changed my source code, I will touch the REDEPLOY file to redeploy the whole EJB application. There is a problem here. Whenever I redeploy my application in weblogic using the above method, the broker will return null record to me. Although the query is valid and the record is certainly inside the database. It just return me with a null record and without any error. But, if I restart the weblogic, everything would be ok. hmm, maybe it's a classpath problem. Are all libraries used by OJB in the same classpath path as ojb.jar? regards, Armin So, I wonder what has gone wrong. Anyone got any idea? Appreciate the help very much, because I have been stuck with this problem for quite a while. Thank you. - 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: JDO - newObjectIdInstance() method failed
Hi Christophe,
The OjbStoreManager implements newObjectIdInstance as follows:
public Object newObjectIdInstance(Class pcClass, String str)
{
return Identity.fromByteArray(str.getBytes());
}
The input this method expects is a String generated by a call to
Identity.serialize()
Identity.toString() does not work!
cheers,
Thomas
Hi,
In the JDO specification, we can find :
public java.lang.Object newObjectIdInstance(java.lang.Class pcClass,
java.lang.String str)
This method returns an object id instance corresponding to
the Class and
String arguments. The String argument might have been the result of
executing toString on an object id instance.
Parameters:
pcClass - the Class of the persistence-capable instance
str - the String form of the object id
Returns:
an instance of the object identity class
I stored the String form of an object id and then tried to rebuild an
object id with the method newObjectIdInstance on the
Persistance Manager.
But it seems OJB doesn't support this feature. I get the following
exception.
Any idea about it ?
Thanks.
java.io.IOException: Not in GZIP format
at
java.util.zip.GZIPInputStream.readHeader(GZIPInputStream.java:129)
at
java.util.zip.GZIPInputStream.init(GZIPInputStream.java:57)
at
java.util.zip.GZIPInputStream.init(GZIPInputStream.java:67)
at
org.apache.ojb.broker.Identity.fromByteArray(Unknown Source)
at
org.apache.ojb.jdori.sql.OjbStoreManager.newObjectIdInstance(U
nknown Source)
at
com.sun.jdori.common.PersistenceManagerImpl.newObjectIdInstanc
e(Unknown
Source)
at
com.sun.jdori.common.PersistenceManagerWrapper.newObjectIdInst
ance(Unknown
Source)
at ...
rethrown as org.apache.ojb.broker.PersistenceBrokerException: Not in
GZIP format
at
org.apache.ojb.broker.Identity.fromByteArray(Unknown Source)
at
org.apache.ojb.jdori.sql.OjbStoreManager.newObjectIdInstance(U
nknown Source)
at
com.sun.jdori.common.PersistenceManagerImpl.newObjectIdInstanc
e(Unknown
Source)
at
com.sun.jdori.common.PersistenceManagerWrapper.newObjectIdInst
ance(Unknown
Source)
at ...
Caused by: java.io.IOException: Not in GZIP format
at
java.util.zip.GZIPInputStream.readHeader(GZIPInputStream.java:129)
at
java.util.zip.GZIPInputStream.init(GZIPInputStream.java:57)
at
java.util.zip.GZIPInputStream.init(GZIPInputStream.java:67)
... 18 more
--
Christophe Demarey,
Research engineer
OpenCCM project - http://www.objectweb.org/openccm
GOAL Team - CNRS/USTL/LIFL - http://www.lifl.fr/GOAL/
Universite des Sciences et Technologies de Lille
LIFL - UMR CNRS 8022- Batiment M3
59655 Villeneuve d'Ascq Cedex - FRANCE
Phone: +33 (0)32043 4728
Fax : +33 (0)32043 6566
-
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]
Incorrect field reference
hello.
please help!
2003-10-28 11:10:45,307 ERROR [STDERR]
org.apache.ojb.broker.OJBRuntimeException: Incorrect field reference
salesPersonId in
[EMAIL PROTECTED]
delete=false,cascade retrieve=true,cascade store=true,is lazy=false,class of
Items=interface domain.Price]
at
org.apache.ojb.broker.metadata.ObjectReferenceDescriptor.getForeignKeyFieldD
escriptors(Unknown Source)
I defined the following interfaces and classes:
public interface Price implements Serializable {
public String getId();
public Article getArticle();
public SalesPerson getSalesPerson();
public double getValue();
}
public class CustomerPriceImpl implements Price {
private String id;
private String articleId;
private String salesPersonId;
private double value;
private SalesPerson salesPerson;// 1:1 reference to Customer
public Customer getSalesPerson() {
return (Customer) salesPerson;
}
}
public interface Article implements Serializable {
public String getId();
public String getArticleNo();
public Collection getPrices();
}
public interface SalesPerson implements Serializable {
public String getId();
public String getName();
public Collection getPrices();
}
public class CustomerImpl implements SalesPerson {
private String id;
private String name;
private Collection prices = new ArrayList(); // 1:n prices
}
the mapping look like:
!-- mapping interface Price --
class-descriptor class=domain.Price
extent-class class-ref=domain.CustomerPriceImpl/
/class-descriptor
class-descriptor class=CustomerPriceImpl
field-descriptor
name=id
column=id
jdbc-type=VARCHAR
autoincrement=true
primarykey=true/
...
reference-descriptor
name=salesPerson
class-ref=domain.CustomerImpl
foreignkey field-ref=salesPersonId/
/reference-descriptor
/class-descriptor
!-- mapping interface SalesPerson --
class-descriptor class=domain.SalesPerson
extent-class class-ref=domain.CustomerImpl/
extent-class class-ref=domain.TraderImpl/
/class-descriptor
class-descriptor class=domain.CustomerImpl
field-descriptor
name=id
column=id
jdbc-type=VARCHAR
autoincrement=true
primarykey=true/
collection-descriptor
name=prices
element-class-ref=domain.Price
proxy=true
auto-retrieve=true
auto-update=true
inverse-foreignkey field-ref=salesPersonId/
/collection-descriptor
/class-descriptor
!-- mapping interface Article --
class-descriptor class=domain.Article
extent-class class-ref=domain.CompetitiveArticleImpl/
/class-descriptor
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Incorrect field reference
Hello,
-Original Message-
From: Reitsam Andreas [mailto:[EMAIL PROTECTED]
2003-10-28 11:10:45,307 ERROR [STDERR]
org.apache.ojb.broker.OJBRuntimeException: Incorrect field reference
salesPersonId in
[EMAIL PROTECTED]
delete=false,cascade retrieve=true,cascade store=true,is
lazy=false,class of
Items=interface domain.Price]
at
org.apache.ojb.broker.metadata.ObjectReferenceDescriptor.getFo
reignKeyFieldD
escriptors(Unknown Source)
public class CustomerPriceImpl implements Price {
...
private String salesPersonId;
...
}
}
!-- mapping interface Price --
class-descriptor class=domain.Price
extent-class class-ref=domain.CustomerPriceImpl/
/class-descriptor
class-descriptor class=domain.CustomerImpl
collection-descriptor
name=prices
element-class-ref=domain.Price
^
you might better use domain.CustomerPriceImpl here
proxy=true
auto-retrieve=true
auto-update=true
inverse-foreignkey field-ref=salesPersonId/
^^^
now OJB expects domain.Price to have a field-descriptor
named salesPersonId.
/collection-descriptor
/class-descriptor
I think you have two ways to fix it:
1. make the type of the reference domain.CustomerPriceImpl, or
2. add a field-descriptor for salesPersonId to the
class-descriptor of domain.Price (I know it is an interface,
but that's o.k.)
HTH,
Olli
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Incorrect field reference (2nd try)
Sorry.
I've forgot to publish the field-descriptor for the salesPersonId:
this is the right version:
2003-10-28 11:10:45,307 ERROR [STDERR]
org.apache.ojb.broker.OJBRuntimeException: Incorrect field reference
salesPersonId in
[EMAIL PROTECTED]
delete=false,cascade retrieve=true,cascade store=true,is lazy=false,class of
Items=interface domain.Price]
at
org.apache.ojb.broker.metadata.ObjectReferenceDescriptor.getForeignKeyFieldD
escriptors(Unknown Source)
I defined the following interfaces and classes:
public interface Price implements Serializable {
public String getId();
public Article getArticle();
public SalesPerson getSalesPerson();
public double getValue();
}
public class CustomerPriceImpl implements Price {
private String id;
private String articleId;
private String salesPersonId;
private double value;
private SalesPerson salesPerson;// 1:1 reference to Customer
public Customer getSalesPerson() {
return (Customer) salesPerson;
}
}
public interface Article implements Serializable {
public String getId();
public String getArticleNo();
public Collection getPrices();
}
public interface SalesPerson implements Serializable {
public String getId();
public String getName();
public Collection getPrices();
}
public class CustomerImpl implements SalesPerson {
private String id;
private String name;
private Collection prices = new ArrayList(); // 1:n prices
}
the mapping look like:
!-- mapping interface Price --
class-descriptor class=domain.Price
extent-class class-ref=domain.CustomerPriceImpl/
/class-descriptor
class-descriptor class=CustomerPriceImpl
field-descriptor
name=id
column=id
jdbc-type=VARCHAR
autoincrement=true
primarykey=true/
...
reference-descriptor
name=salesPerson
class-ref=domain.CustomerImpl
foreignkey field-ref=salesPersonId/
/reference-descriptor
/class-descriptor
!-- mapping interface SalesPerson --
class-descriptor class=domain.SalesPerson
extent-class class-ref=domain.CustomerImpl/
extent-class class-ref=domain.TraderImpl/
/class-descriptor
class-descriptor class=domain.CustomerImpl
field-descriptor
name=id
column=id
jdbc-type=VARCHAR
autoincrement=true
primarykey=true/
field-descriptor
name=salesPersonId
column=customer_Id
jdbc-type=VARCHAR/
collection-descriptor
name=prices
element-class-ref=domain.Price
proxy=true
auto-retrieve=true
auto-update=true
inverse-foreignkey field-ref=salesPersonId/
/collection-descriptor
/class-descriptor
!-- mapping interface Article --
class-descriptor class=domain.Article
extent-class class-ref=domain.CompetitiveArticleImpl/
/class-descriptor
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 28. Oktober 2003 12:05
An: [EMAIL PROTECTED]
Betreff: RE: Incorrect field reference
Hello,
-Original Message-
From: Reitsam Andreas [mailto:[EMAIL PROTECTED]
2003-10-28 11:10:45,307 ERROR [STDERR]
org.apache.ojb.broker.OJBRuntimeException: Incorrect field reference
salesPersonId in
[EMAIL PROTECTED]
delete=false,cascade retrieve=true,cascade store=true,is
lazy=false,class of
Items=interface domain.Price]
at
org.apache.ojb.broker.metadata.ObjectReferenceDescriptor.getFo
reignKeyFieldD
escriptors(Unknown Source)
public class CustomerPriceImpl implements Price {
...
private String salesPersonId;
...
}
}
!-- mapping interface Price --
class-descriptor class=domain.Price
extent-class class-ref=domain.CustomerPriceImpl/
/class-descriptor
class-descriptor class=domain.CustomerImpl
collection-descriptor
name=prices
element-class-ref=domain.Price
^
you might better use domain.CustomerPriceImpl here
proxy=true
auto-retrieve=true
auto-update=true
inverse-foreignkey field-ref=salesPersonId/
^^^
now OJB expects domain.Price to have a field-descriptor
named salesPersonId.
/collection-descriptor
/class-descriptor
I think you have two ways to fix it:
1. make the type of the reference domain.CustomerPriceImpl, or
2. add a field-descriptor for salesPersonId to the
class-descriptor of domain.Price (I know it is an interface,
but that's o.k.)
HTH,
Olli
Proposal - newObjectIdInstance / Identity JDO compliant
Hi all,
if the String argument is the result of As I said in my last mail, the
PersistenceManager.newObjectIdInstance(Class pcClass, String str) failed
executing toString on an object id instance.
With OJB,
newObjectIdInstance(Class pcClass, Identity.toString()) does not work!
We got a java.io.IOException: Not in GZIP format.
We must use newObjectIdInstance(Class pcClass, Identity.serialize()).
But this method does not appear in the JDO specification :=(.
So, if one want to use ObjectId with JDO, its software application is
dependant on OJB and can't be used with another OJB implementation.
I think it could be usefull to rename the Identity.toString() method and
to implement a new Identity.toString() method :
public String toString()
{
return new String( serialize() );
}
In this case, OJB will become JDO compliant with ObjectId.
I don't know if the actual Identity.toString() method is often used but
I think rename this method will not change a big part of OJB. Am I wrong?
Best Regards.
PS: Thanks to Thomas Mahler for its explanation.
--
Christophe Demarey,
Research engineer
OpenCCM project - http://www.objectweb.org/openccm
GOAL Team - CNRS/USTL/LIFL - http://www.lifl.fr/GOAL/
Universite des Sciences et Technologies de Lille
LIFL - UMR CNRS 8022- Batiment M3
59655 Villeneuve d'Ascq Cedex - FRANCE
Phone: +33 (0)32043 4728
Fax : +33 (0)32043 6566
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Threads?
Does OJB start any threads of it's own volition? -- David Corbin [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Threads?
Hi David, David Corbin wrote: Does OJB start any threads of it's own volition? AFAIK nope! But I don't know the used libraries in detail, e.g. have a look at commons-dbcp and commons-pool (maybe in some special configurations intern threads will be started), in some cases jdbc-drivers start their own timer thread to handle connection timeout stuff. regards, Armin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 not
Oracle Auto-Increment
Hello, I´m new on the list, I think that someone already have this problem: - OJB can´t work with my Oracle 8i Auto-Increment columns... If you can help, please, it´s very important... Thanks Ronald
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: Oracle Auto-Increment
Hi Roland, using sequences works very well cheers danilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Oracle Auto-Increment
Turn batch-mode off and then try your test. If it works, you'll need the fix for this. You can either patch ti yourself, or take the latest CVS image. On Tue, 2003-10-28 at 10:08, Ronald Paloschi wrote: Hi Danilo, I will try to explain a little better (forgive the errors... Im brazillian... hehe :-) First: Im not a DB expert. The DBA have done the all the sequences. They work perfect outside OJB. Well, considering that I have a Oracle Database Setup and OK, with sequences and all... right? My doubt is on OJB, when I try to use the store() method I get an java.lang.ClassCastException. Can you send the pieces of the repository_user and repository_database to me? I think my error is there, because the database is already in use at a long time, without problems in a Client/Server application. You can do that? Thanks for the support!!! []s Ronald - Original Message - From: Danilo Tommasina [EMAIL PROTECTED] To: OJB Users List [EMAIL PROTECTED] Sent: Tuesday, October 28, 2003 12:58 PM Subject: Re: Oracle Auto-Increment Hi Roland, using sequences works very well cheers danilo - 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]
RE: how to get objects locked by a transaction?
Hello Jair,
OJB ODMG stores each registered Objects in an o.a.ojb.odmg.ObjectEnvelope.
All ObjectEnvelopes are kept in an o.a.ojb.odmg.ObjectEnvelopeTable.
ObjectEnvelopeTable has a public method
public Enumeration elements();
which returns an Enumeration of all ObjectEnvelopes.
The each OJB ODMG TransactionImpl maintains its own ObjectEnvelopeTable:
/**
* the internal table containing all Objects touched by this tx and
their
* respective transactional state
*/
private ObjectEnvelopeTable objectEnvelopeTable = null;
Currently TransactionImpl does not provide public access to the
ObjectEnvelopeTable.
So I don't see a way to perform your task without changing OJB code...
cheers,
Thomas
-Original Message-
From: Jair da Silva Ferreira Júnior [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 28, 2003 12:25 AM
To: OJB Users List
Subject: how to get objects locked by a transaction?
Hello,
How can I safely get all objects locked by a transaction
using ODMG or broker API?
I need this because I want to remove all objects locked
by a transaction from the cache. Something like this:
.
Iterator lockedObjects=getLockedObjects(transaction);
while(lockedObjects.hasNext()){
broker.removeFromCache(lockedObjects.next());
}
.
Thanks,
Jair Jr
-
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. The
Re: how to get objects locked by a transaction?
Hi,
Thank you Mahler for your fast reply.
I understand that it is not possible to do it with the current OJB API.
I am asking you this because I need to remove from OJB cache the objects
touched by a transaction when it is aborted.
Here is what I think could be a good idea to fix this issue: as noted in
the OJB cache documentation (http://db.apache.org/ojb/objectcache.html), the
OJB user must manually remove each object touched by the trasaction when
using ObjectCacheDefaultImpl and the transaction is aborted because the
objects may be corrupted. So why doesn't the implementation of the
Transaction.abort method removes the touched objets from the cache? I think
this should fix this issue, don't you?
Well, it's just an idea. In my system I am going to remove the objects
from cache manually, but as there's no way to get only the objects touched
by the transaction I'll have to clear the entire cache.
Thanks,
Jair Jr
- Original Message -
From: Mahler Thomas [EMAIL PROTECTED]
To: 'OJB Users List' [EMAIL PROTECTED]
Sent: Tuesday, October 28, 2003 1:45 PM
Subject: RE: how to get objects locked by a transaction?
Hello Jair,
OJB ODMG stores each registered Objects in an o.a.ojb.odmg.ObjectEnvelope.
All ObjectEnvelopes are kept in an o.a.ojb.odmg.ObjectEnvelopeTable.
ObjectEnvelopeTable has a public method
public Enumeration elements();
which returns an Enumeration of all ObjectEnvelopes.
The each OJB ODMG TransactionImpl maintains its own ObjectEnvelopeTable:
/**
* the internal table containing all Objects touched by this tx and
their
* respective transactional state
*/
private ObjectEnvelopeTable objectEnvelopeTable = null;
Currently TransactionImpl does not provide public access to the
ObjectEnvelopeTable.
So I don't see a way to perform your task without changing OJB code...
cheers,
Thomas
-Original Message-
From: Jair da Silva Ferreira Júnior [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 28, 2003 12:25 AM
To: OJB Users List
Subject: how to get objects locked by a transaction?
Hello,
How can I safely get all objects locked by a transaction
using ODMG or broker API?
I need this because I want to remove all objects locked
by a transaction from the cache. Something like this:
.
Iterator lockedObjects=getLockedObjects(transaction);
while(lockedObjects.hasNext()){
broker.removeFromCache(lockedObjects.next());
}
.
Thanks,
Jair Jr
-
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: Optimistic Locking using the PersistenceBroker API
Yes, we use it. It is really easy. You need a field in each table which is either integer or timestamp. I use integer. And then you need to identify this in your repository_user.xml. The entry looks like this : field-descriptor id=1 name=rowVersion column=rowVersion jdbc-type=INTEGER locking=true / I believe that's all. If you get a violation, an OptimisticLockException is thrown. Bonnie MacKellar -Original Message- From: Andy Czerwonka To: OJB Users List Sent: 10/28/03 2:43 PM Subject: Optimistic Locking using the PersistenceBroker API Has anyone implemented an optimistic-locking strategy (I actually may need a Pessimistic strategy - not sure yet) using the PersistenceBroker API? Can you point me in the right direction? -andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Conditional auto-update/best practices
Hello, I've tried searching the archives for a solution to what should be a common problem. Sometimes I want to persist an object graph that maps to multiple tables in my database. OJB handles it beautifully when I set it the reference-descriptor's auto-update attribute to true. However, there are times when I only want to update the main table. I get into problems when I try to persist the object without the related objects because I usually get a CANNOT INSERT A NULL error in the related tables. Therefore, my question is, can you set the auto-update conditionally? Or am i REQUIRED to create all the related objects even if I only want to save the main object? I'm also wondering if I just am on the wrong track. After reading Professional Struts Applications (Wrox), a particular line is hinting that maybe I'm missing something. They say, A Value Object is nothing more than a view of the data and there is nothing inappropriate about having a DAO return different types of Value Objects, all showing a different perspective of the same piece of data. This seems to hint that perhaps I should create a separate Value Object (with its own metadata in repository_user.xml) for when I want to persist an object without its related objects. This seems messy because it increases maintenance if the object definition changes (I'll have to change it in more than one place). Is this the standard, or best practice? What is everyone else doing? Thanks, Anthony Carlos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
