perhaps already ask
Hi, Is there any possibility, without using QueryBySQL , to create a query join over two tables which not have relationship-definition ? Thanks a lot. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RE : UPGRADE pb with proxi and getCollectionByQuery
Hi, Some time ago, I ran a comparison of MSSql drivers. http://article.gmane.org/gmane.comp.jakarta.ojb.user/7367 http://article.gmane.org/gmane.comp.jakarta.ojb.user/7369 (Note The first link contained errors which I updated in the second reference) As I said in the original post, the benchmarks are derived from part of our application - so your results may vary. In essence, the only way to find out the best driver for your application is do what we've done - test them. Having said all that, we're still using the MS driver in the development team, because it works and is free. Cheers, Charles. -Original Message- From: Emmanuel Dupont [mailto:[EMAIL PROTECTED] Sent: 09 October 2003 07:37 To: 'OJB Users List'; [EMAIL PROTECTED] Subject: RE : UPGRADE pb with proxi and getCollectionByQuery Hi Armin ! In fact it seems that it is a driver error. We are using MSSQL server with jtds driver. I retrieve from db a proxy object; I set its attributes and lock with UPGRADE (even WRITE) mode in order to make an update database. I commit but nothing happens. No update is done!!! I'm obliged to create a new jdo, set the attributes, lock with WRITE and commit, if I want an update to be done. This is very weird because it seems that sometimes the update is well done in the first case. It's very strange. Do you really recommend the j-netdirect driver ? Is this driver quicker and most of all safer ? Emmanuel. -Message d'origine- De : Armin Waibel [mailto:[EMAIL PROTECTED] Envoyé : mercredi 8 octobre 2003 02:16 À : OJB Users List Objet : Re: UPGRADE pb with proxi and getCollectionByQuery Hi Emmanuel, can you post your test code, then we are able to write a test case. regards, Armin On Mon, 6 Oct 2003 19:57:26 +0200, Emmanuel Dupont [EMAIL PROTECTED] wrote: All, I have this strange behaviours. When I call getCollectionByQuery I retrieve a collection of proxy objects. Now, I want to modify some attributes of these objects and after I lock with the UPGRADE mode and commit. No update is generated. The object is not make as dirty. Why ?? When I use getObjectByQuery I don't have the trouble my object is well updated!!! Any helps would be appreciated, this is driving me nuts! Tx ! Ps : I 'm using the : ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheEmptyImpl - 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] This email and any attachments are strictly confidential and are intended solely for the addressee. If you are not the intended recipient you must not disclose, forward, copy or take any action in reliance on this message or its attachments. If you have received this email in error please notify the sender as soon as possible and delete it from your computer systems. Any views or opinions presented are solely those of the author and do not necessarily reflect those of HPD Software Limited or its affiliates. At present the integrity of email across the internet cannot be guaranteed and messages sent via this medium are potentially at risk. All liability is excluded to the extent permitted by law for any claims arising as a re- sult of the use of this medium to transmit information by or to HPD Software Limited or its affiliates. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE : RE : UPGRADE pb with proxi and getCollectionByQuery
Thanks a lot. -Message d'origine- De : Charles Anthony [mailto:[EMAIL PROTECTED] Envoyé : jeudi 9 octobre 2003 08:55 À : 'OJB Users List' Objet : RE: RE : UPGRADE pb with proxi and getCollectionByQuery Hi, Some time ago, I ran a comparison of MSSql drivers. http://article.gmane.org/gmane.comp.jakarta.ojb.user/7367 http://article.gmane.org/gmane.comp.jakarta.ojb.user/7369 (Note The first link contained errors which I updated in the second reference) As I said in the original post, the benchmarks are derived from part of our application - so your results may vary. In essence, the only way to find out the best driver for your application is do what we've done - test them. Having said all that, we're still using the MS driver in the development team, because it works and is free. Cheers, Charles. -Original Message- From: Emmanuel Dupont [mailto:[EMAIL PROTECTED] Sent: 09 October 2003 07:37 To: 'OJB Users List'; [EMAIL PROTECTED] Subject: RE : UPGRADE pb with proxi and getCollectionByQuery Hi Armin ! In fact it seems that it is a driver error. We are using MSSQL server with jtds driver. I retrieve from db a proxy object; I set its attributes and lock with UPGRADE (even WRITE) mode in order to make an update database. I commit but nothing happens. No update is done!!! I'm obliged to create a new jdo, set the attributes, lock with WRITE and commit, if I want an update to be done. This is very weird because it seems that sometimes the update is well done in the first case. It's very strange. Do you really recommend the j-netdirect driver ? Is this driver quicker and most of all safer ? Emmanuel. -Message d'origine- De : Armin Waibel [mailto:[EMAIL PROTECTED] Envoyé : mercredi 8 octobre 2003 02:16 À : OJB Users List Objet : Re: UPGRADE pb with proxi and getCollectionByQuery Hi Emmanuel, can you post your test code, then we are able to write a test case. regards, Armin On Mon, 6 Oct 2003 19:57:26 +0200, Emmanuel Dupont [EMAIL PROTECTED] wrote: All, I have this strange behaviours. When I call getCollectionByQuery I retrieve a collection of proxy objects. Now, I want to modify some attributes of these objects and after I lock with the UPGRADE mode and commit. No update is generated. The object is not make as dirty. Why ?? When I use getObjectByQuery I don't have the trouble my object is well updated!!! Any helps would be appreciated, this is driving me nuts! Tx ! Ps : I 'm using the : ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheEmptyImpl - 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] This email and any attachments are strictly confidential and are intended solely for the addressee. If you are not the intended recipient you must not disclose, forward, copy or take any action in reliance on this message or its attachments. If you have received this email in error please notify the sender as soon as possible and delete it from your computer systems. Any views or opinions presented are solely those of the author and do not necessarily reflect those of HPD Software Limited or its affiliates. At present the integrity of email across the internet cannot be guaranteed and messages sent via this medium are potentially at risk. All liability is excluded to the extent permitted by law for any claims arising as a re- sult of the use of this medium to transmit information by or to HPD Software Limited or its affiliates. - 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: Inheritance problem
hi balza? ,
ojb is not able to find the fields defined in the superclass. this
problem was fixed some time ago. there are also testcases in
AnonymousFieldTest that successfully query fields in superclass.
please get the latest from repository.
hth
jakob
balza wrote:
Hello,
* the class-descriptors:
class-descriptor class=allibo.core.Account table=c_account
field-descriptor name=account_id column=account_id
jdbc-type=INTEGER primarykey=true autoincrement=true/
field-descriptor name=login column=login jdbc-type=VARCHAR/
field-descriptor name=password column=password
jdbc-type=VARCHAR/
field-descriptor name=first_name column=first_name
jdbc-type=VARCHAR/
field-descriptor name=last_name column=last_name
jdbc-type=VARCHAR/
field-descriptor name=gender column=gender jdbc-type=VARCHAR/
field-descriptor name=remark column=remark jdbc-type=VARCHAR/
field-descriptor name=email column=email jdbc-type=VARCHAR/
field-descriptor name=registration_date column=registration_date
jdbc-type=DATE/
field-descriptor name=last_activity_date
column=last_activity_date jdbc-type=DATE/
field-descriptor name=date_of_birth column=date_of_birth
jdbc-type=DATE/
/class-descriptor
class-descriptor class=allibo.commerce.Employee table=fem_employee
field-descriptor name=account_id column=account_id
jdbc-type=INTEGER primarykey=true autoincrement=true/
reference-descriptor name=super class-ref=allibo.core.Account
auto-retrieve=true auto-update=true auto-delete=true
foreignkey field-ref=account_id/
/reference-descriptor /class-descriptor
public class Account { public Organization organization;
public AccountAddress accountAddress;
private int account_id;
private String login;
private String password;
private String first_name;
private String last_name;
private String gender;
private String remark;
private String email;
private Date registration_date;
private Date last_activity_date;
private Date date_of_birth;
+ setter getter methods
public class Employee extends Account {
private int account_id; private Account account;
+ setter getter methods
* The code:
public void apply() {
//Query OJB Criteria crit = new Criteria();
logger.debug(login : + login);
logger.debug(password : + password);
crit.addEqualTo(login, login);
crit.addEqualTo(password, password); Query q
= QueryFactory.newQuery(Employee.class, crit); try {
Collection results = broker.getCollectionByQuery(q);
Iterator it = results.iterator();
if (it.hasNext()) {
employee = (Employee) it.next();
logger.debug(First name + employee.getFirst_name());
}
} catch (Throwable t) {
t.printStackTrace();
}
}
* The log
2063 [main] DEBUG allibo.commerce.UCFindEmployeeTest - employee :1082
2073 [main] INFO allibo.commerce.UCFindEmployeeTest - testApply
2073 [main] DEBUG allibo.commerce.UCFindEmployee - login :employee
2073 [main] DEBUG allibo.commerce.UCFindEmployee - password :employee
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:SELECT A0.account_id FROM fem_employee A0 WHERE (login = ? ) AND
password = ?
java.sql.SQLException: Column not found, message from server: Unknown
column 'login' in 'where clause'
[org.apache.ojb.broker.accesslayer.JdbcAccessImpl] ERROR: SQLException
during the execution of the query (for a allibo.commerce.Employee):
Column not found, message from server: Unknown column 'login' in
'where clause'
Column not found, message from server: Unknown column 'login' in
'where clause'
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:1626)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:886)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:945)
at com.mysql.jdbc.Connection.execSQL(Connection.java:1844)
at
com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1458)
at
org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(Unknown
Source)
at org.apache.ojb.broker.accesslayer.RsIterator.init(Unknown Source)
at
org.apache.ojb.broker.core.RsIteratorFactoryImpl.createRsIterator(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getRsIteratorFromQuery(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getIteratorFromQuery(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknown
Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(Unknown
Source)
at
Choose columns to update
Hi all, I need to tell OJB which columns to update when persisting an object (instead of updating all mapped fields). Can anybody please tell me how to do this? Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Choose columns to update
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 09 October 2003 11:01 To: [EMAIL PROTECTED] Subject: Choose columns to update Hi all, I need to tell OJB which columns to update when persisting an object (instead of updating all mapped fields). Can anybody please tell me how to do this? Hi, I'm sorry no-one replied before. In short, this is not currently possible with OJB. I have a sneaking suspicion that this is *not* a trivial thing to do; as you may have noticed from the list, the developers are currently trying to work towards a 1.0 release in the near future (maybe via an rc5) - such a substantial feature request would be unlikely to make into a release in the near future. Of course, I may be talking complete rubbish - in which case one of the committers should respond - but I thought I'd reply just so you don't think we are ignoring you on purpose. Cheers, Charles. This email and any attachments are strictly confidential and are intended solely for the addressee. If you are not the intended recipient you must not disclose, forward, copy or take any action in reliance on this message or its attachments. If you have received this email in error please notify the sender as soon as possible and delete it from your computer systems. Any views or opinions presented are solely those of the author and do not necessarily reflect those of HPD Software Limited or its affiliates. At present the integrity of email across the internet cannot be guaranteed and messages sent via this medium are potentially at risk. All liability is excluded to the extent permitted by law for any claims arising as a re- sult of the use of this medium to transmit information by or to HPD Software Limited or its affiliates. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SQL generation bug
Hello, RC4 and DB2 The parameters in prepared statements are replaced incorrectly. Integers, long etc. are all surrounded by quotes! I modified PlatformDb2Impl.setObjectForStatement(...) to send the correct set-method to the prepared statement for these types. Now that works fine (did anyone uses OJB for DB2 before?). The weird thing: in the where condition of update statements, the values still were not correctly set (quotes for integers). I had a look into StatementManager.bindUpdate and replaced there the line stmt.setObject(index, values[i], SqlHelper.getSqlTypePk(cld, i)); with m_platform.setObjectForStatement(stmt, index, values[i], SqlHelper.getSqlTypePk(cld, i)); Now this seems to work too. Is the patch correct (please confirm/refuse) or were there good reasons for using stmt.setObject(...)? (This is not DB2 specific, how comes no-one else reports problems??) Thanks, Norbert. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SQL generation bug
Hi, [...] (did anyone uses OJB for DB2 before?). Yep - we're using OJB on DB2/400, with no major problems. Cheers, Charles. This email and any attachments are strictly confidential and are intended solely for the addressee. If you are not the intended recipient you must not disclose, forward, copy or take any action in reliance on this message or its attachments. If you have received this email in error please notify the sender as soon as possible and delete it from your computer systems. Any views or opinions presented are solely those of the author and do not necessarily reflect those of HPD Software Limited or its affiliates. At present the integrity of email across the internet cannot be guaranteed and messages sent via this medium are potentially at risk. All liability is excluded to the extent permitted by law for any claims arising as a re- sult of the use of this medium to transmit information by or to HPD Software Limited or its affiliates. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Choose columns to update
Thanks for your reply. Could you please give me a hint how to achieve this anyhow? We're planning a dirty workaround: Having a class with a static method called by PersistenceBroker store(Object, ObjectModification) after retrieving the class descriptor. That method clones and modifies the affected class descriptor as desired, depending on the object processed. The risk: If somewhere in the framework the class descriptor is not passed as parameter but instead looked up from the repository again, we're lost. How safe is this approach? Any other idea is highly appreciated. Thanks, Norbert. -Original Message- From: Charles Anthony [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 09. Oktober 2003 12:04 To: 'OJB Users List' Subject: RE: Choose columns to update -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 09 October 2003 11:01 To: [EMAIL PROTECTED] Subject: Choose columns to update Hi all, I need to tell OJB which columns to update when persisting an object (instead of updating all mapped fields). Can anybody please tell me how to do this? Hi, I'm sorry no-one replied before. In short, this is not currently possible with OJB. I have a sneaking suspicion that this is *not* a trivial thing to do; as you may have noticed from the list, the developers are currently trying to work towards a 1.0 release in the near future (maybe via an rc5) - such a substantial feature request would be unlikely to make into a release in the near future. Of course, I may be talking complete rubbish - in which case one of the committers should respond - but I thought I'd reply just so you don't think we are ignoring you on purpose. Cheers, Charles. This email and any attachments are strictly confidential and are intended solely for the addressee. If you are not the intended recipient you must not disclose, forward, copy or take any action in reliance on this message or its attachments. If you have received this email in error please notify the sender as soon as possible and delete it from your computer systems. Any views or opinions presented are solely those of the author and do not necessarily reflect those of HPD Software Limited or its affiliates. At present the integrity of email across the internet cannot be guaranteed and messages sent via this medium are potentially at risk. All liability is excluded to the extent permitted by law for any claims arising as a re- sult of the use of this medium to transmit information by or to HPD Software Limited or its affiliates. - 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]
OJB maintenance branch - who volunteers?
Hello, I would like to re-open this discussion that has frequently been addressed, even in ongoing threads. I assume that every OJB user who ships his software to his customers will want to have a stable version of OJB but still need bugfixes from time to time. If we do not branch a maintenance version, we will never reach such stability. Consequently, each user will probably have to maintain his private version of OJB. I believe that the overall time spent this way is pretty high. Even if only 5 or 6 users cooperate, they can maintain a CVS branch or module and save time this way. Thomas has already made clear that he does not have enough time to manage a maintenance branch, but maybe we can find a few people who volunteer for that job. Maybe it is possible to have allow them CVS commit only for the maintenance subproject? Reasding the other postings, I understand that there is consensus that version 1.0.0 is a canonical or even self-evident point to create such a branch. I propose to create that branch (or extra modul) asap and then develop versions 1.0.x there. I offer to help maintain that branch or module. Olli -- Oliver Matz ppi Media GmbH Deliusstraße 10 D-24114 Kiel phone +49 (0) 43 1-53 53-422 fax +49 (0) 43 1-53 53-2 22 email mailto:[EMAIL PROTECTED] web www.ppi.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ConcurrentModificationException
Hi Armin, I have an object with an init method where I assign a PersistenceBroker instance using PersistenceBrokerFactory.defaultPersistenceBroker() This object then has an onEvent() method that is called and uses broker.store(). I tried modifying the object so that the broker is obtained in the onEvent instead of the init and I started getting Borrow broker from pool failed Exceptions. I have my connection-pool set up as follows: connection-pool maxActive=-1 whenExhaustedAction=2 validationQuery=select 1 from t_client/ Do you have any suggestions for what I might be doing wrong? Mike - Original Message - From: Armin Waibel [EMAIL PROTECTED] To: OJB Users List [EMAIL PROTECTED] Sent: Wednesday, October 08, 2003 6:02 PM Subject: Re: ConcurrentModificationException Hi Michael, On Wed, 8 Oct 2003 17:31:15 +0100, Michael Watson [EMAIL PROTECTED] wrote: Hi all, I'm finding I quite reguarly get this exception when I'm attempting to call PersistenceBroker.store(Object) from multiple threads simultaneously. Do several threads share the same PB instance? If so, this is not allowed. PB instances are not threadsafe itself, but they are pooled so it's no performance impact to use a separate PB instance for each thread. regards, Armin ?xml version='1.0'? exception cause detailMessage/ exceptionClassjava.util.ConcurrentModificationException/exceptionClass stackTrace stackTracejava.util.AbstractList$Itr.checkForComodification(AbstractList.j ava:444)/stackTrace stackTracejava.util.AbstractList$Itr.next(AbstractList.java:417)/stackTra ce stackTracejava.util.AbstractCollection.remove(AbstractCollection.java:250) /stackTrace stackTraceorg.apache.ojb.broker.core.PersistenceBrokerImpl.store(Unknown Source)/stackTrace stackTraceorg.apache.ojb.broker.core.PersistenceBrokerImpl.store(Unknown Source)/stackTrace stackTraceorg.apache.ojb.broker.core.DelegatingPersistenceBroker.store(Unk nown Source)/stackTrace ... /stackTrace /cause detailMessageFailed to update History record java.util.ConcurrentModificationException/detailMessage exceptionClassorg.apache.ojb.broker.PersistenceBrokerException/exceptionC lass stackTrace/ /exception Obviously somewhere in the broker there's been an attempt to modify the structure of a list by 2 or more threads simultaneously. My question is, has anything been done to prevent this in a newer version or should I just catch these exceptions and retry the store? I'm using ojb-1.0.rc3 at the moment. Regards, Mike - 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: ConcurrentModificationException
Hi,
You need to ensure that you are closing the broker.
public void onEvent(){
PersistenceBroker pb =
PersistenceBrokerFactory.defaultPersistenceBroker();
pb.store(this); // or whatever it is you want to do with the broker
pb.close();
}
You should only get brokers when you need them, and close them when you've
finished with them.
HTH,
Charles.
-Original Message-
From: Michael Watson [mailto:[EMAIL PROTECTED]
Sent: 09 October 2003 12:53
To: OJB Users List; [EMAIL PROTECTED]
Subject: Re: ConcurrentModificationException
Hi Armin,
I have an object with an init method where I assign a
PersistenceBroker
instance using
PersistenceBrokerFactory.defaultPersistenceBroker()
This object then has an onEvent() method that is called and uses
broker.store().
I tried modifying the object so that the broker is obtained
in the onEvent
instead of the init and I started getting
Borrow broker from pool failed Exceptions. I have my
connection-pool set
up as follows:
connection-pool maxActive=-1 whenExhaustedAction=2
validationQuery=select 1 from t_client/
Do you have any suggestions for what I might be doing wrong?
Mike
- Original Message -
From: Armin Waibel [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]
Sent: Wednesday, October 08, 2003 6:02 PM
Subject: Re: ConcurrentModificationException
Hi Michael,
On Wed, 8 Oct 2003 17:31:15 +0100, Michael Watson
[EMAIL PROTECTED] wrote:
Hi all,
I'm finding I quite reguarly get this exception when I'm
attempting to
call
PersistenceBroker.store(Object) from multiple threads
simultaneously.
Do several threads share the same PB instance?
If so, this is not allowed. PB instances are not
threadsafe itself, but they are pooled so it's no
performance impact to use a separate PB instance for each thread.
regards,
Armin
?xml version='1.0'?
exception
cause
detailMessage/
exceptionClassjava.util.ConcurrentModificationException/exc
eptionClass
stackTrace
stackTracejava.util.AbstractList$Itr.checkForComodification(
AbstractList.j
ava:444)/stackTrace
stackTracejava.util.AbstractList$Itr.next(AbstractList.java:
417)/stackTra
ce
stackTracejava.util.AbstractCollection.remove(AbstractCollec
tion.java:250)
/stackTrace
stackTraceorg.apache.ojb.broker.core.PersistenceBrokerImpl.s
tore(Unknown
Source)/stackTrace
stackTraceorg.apache.ojb.broker.core.PersistenceBrokerImpl.s
tore(Unknown
Source)/stackTrace
stackTraceorg.apache.ojb.broker.core.DelegatingPersistenceBr
oker.store(Unk
nown Source)/stackTrace
...
/stackTrace
/cause
detailMessageFailed to update History record
java.util.ConcurrentModificationException/detailMessage
exceptionClassorg.apache.ojb.broker.PersistenceBrokerExcepti
on/exceptionC
lass
stackTrace/
/exception
Obviously somewhere in the broker there's been an attempt
to modify the
structure of a list by 2 or more threads simultaneously.
My question is, has anything been done to prevent this in a newer
version or
should I just catch these exceptions and retry the store?
I'm using ojb-1.0.rc3 at the moment.
Regards,
Mike
-
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]
This email and any attachments are strictly confidential and are intended
solely for the addressee. If you are not the intended recipient you must
not disclose, forward, copy or take any action in reliance on this message
or its attachments. If you have received this email in error please notify
the sender as soon as possible and delete it from your computer systems.
Any views or opinions presented are solely those of the author and do not
necessarily reflect those of HPD Software Limited or its affiliates.
At present the integrity of email across the internet cannot be guaranteed
and messages sent via this medium are potentially at risk. All liability
is excluded to the extent permitted by law for any claims arising as a re-
sult of the use of this medium to transmit information by or to
HPD Software Limited or its affiliates.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ConcurrentModificationException
Oops.
Thanks Charles.
- Original Message -
From: Charles Anthony [EMAIL PROTECTED]
To: 'OJB Users List' [EMAIL PROTECTED]
Sent: Thursday, October 09, 2003 12:52 PM
Subject: RE: ConcurrentModificationException
Hi,
You need to ensure that you are closing the broker.
public void onEvent(){
PersistenceBroker pb =
PersistenceBrokerFactory.defaultPersistenceBroker();
pb.store(this); // or whatever it is you want to do with the broker
pb.close();
}
You should only get brokers when you need them, and close them when you've
finished with them.
HTH,
Charles.
-Original Message-
From: Michael Watson [mailto:[EMAIL PROTECTED]
Sent: 09 October 2003 12:53
To: OJB Users List; [EMAIL PROTECTED]
Subject: Re: ConcurrentModificationException
Hi Armin,
I have an object with an init method where I assign a
PersistenceBroker
instance using
PersistenceBrokerFactory.defaultPersistenceBroker()
This object then has an onEvent() method that is called and uses
broker.store().
I tried modifying the object so that the broker is obtained
in the onEvent
instead of the init and I started getting
Borrow broker from pool failed Exceptions. I have my
connection-pool set
up as follows:
connection-pool maxActive=-1 whenExhaustedAction=2
validationQuery=select 1 from t_client/
Do you have any suggestions for what I might be doing wrong?
Mike
- Original Message -
From: Armin Waibel [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]
Sent: Wednesday, October 08, 2003 6:02 PM
Subject: Re: ConcurrentModificationException
Hi Michael,
On Wed, 8 Oct 2003 17:31:15 +0100, Michael Watson
[EMAIL PROTECTED] wrote:
Hi all,
I'm finding I quite reguarly get this exception when I'm
attempting to
call
PersistenceBroker.store(Object) from multiple threads
simultaneously.
Do several threads share the same PB instance?
If so, this is not allowed. PB instances are not
threadsafe itself, but they are pooled so it's no
performance impact to use a separate PB instance for each thread.
regards,
Armin
?xml version='1.0'?
exception
cause
detailMessage/
exceptionClassjava.util.ConcurrentModificationException/exc
eptionClass
stackTrace
stackTracejava.util.AbstractList$Itr.checkForComodification(
AbstractList.j
ava:444)/stackTrace
stackTracejava.util.AbstractList$Itr.next(AbstractList.java:
417)/stackTra
ce
stackTracejava.util.AbstractCollection.remove(AbstractCollec
tion.java:250)
/stackTrace
stackTraceorg.apache.ojb.broker.core.PersistenceBrokerImpl.s
tore(Unknown
Source)/stackTrace
stackTraceorg.apache.ojb.broker.core.PersistenceBrokerImpl.s
tore(Unknown
Source)/stackTrace
stackTraceorg.apache.ojb.broker.core.DelegatingPersistenceBr
oker.store(Unk
nown Source)/stackTrace
...
/stackTrace
/cause
detailMessageFailed to update History record
java.util.ConcurrentModificationException/detailMessage
exceptionClassorg.apache.ojb.broker.PersistenceBrokerExcepti
on/exceptionC
lass
stackTrace/
/exception
Obviously somewhere in the broker there's been an attempt
to modify the
structure of a list by 2 or more threads simultaneously.
My question is, has anything been done to prevent this in a newer
version or
should I just catch these exceptions and retry the store?
I'm using ojb-1.0.rc3 at the moment.
Regards,
Mike
-
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]
This email and any attachments are strictly confidential and are intended
solely for the addressee. If you are not the intended recipient you must
not disclose, forward, copy or take any action in reliance on this message
or its attachments. If you have received this email in error please notify
the sender as soon as possible and delete it from your computer systems.
Any views or opinions presented are solely those of the author and do not
necessarily reflect those of HPD Software Limited or its affiliates.
At present the integrity of email across the internet cannot be
guaranteed
and messages sent via this medium are potentially at risk. All liability
is excluded to the extent permitted by law for any claims arising as a re-
sult of the use of this medium to transmit information by or to
HPD Software Limited or its
RE: Choose columns to update
Norbert -- As far as excluding certain columns from an insert/update statement, setting the 'access' property on an field-descriptor to 'readonly' will cause that field/column to be excluded from any insert/update statement that is generated by ojb. As far as getting OJB to issue an insert statement in lieu of an update statement, the PersistenceBroker interface defines two methods for storing objects: public void store(Object obj); public void store(Object obj, ObjectModification modification); If you call the second version of this method and pass org.apache.ojb.broker.util.ObjectModificationDefaultImpl#INSERT for the 'modification' argument, then ojb will issue an insert statement. Ron Gallagher Atlanta, GA [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 08, 2003 10:13 AM To: [EMAIL PROTECTED] Subject: Choose columns to update Hi all, we use OJB1.0 RC4 against a DB2. We want to tell OJB which columns should be included in the update statement instead of updating all of them. The columns to update have the same name and definition in all the tables. Detailled information: We have tables with many columns. Some columns hold only 'technical' information like lastupdate timestamp and occur in each table. Whenever a record is modified, we *insert* a new one and update these technical attributes of the previously valid record (i.e. we are historizing the changes). The tables also have many indexes. Therefore, updates on all fields are costy (beside the bigger effort to build the query, higher network traffic to the database and the obvious bigger overhead for the database, it seems that these non-affected fields also cause costy index calculations ond the database if incuded in the update). What we actually need would be another descriptor for each table which describes only this subset of columns to update. But this would cause many more descriptors and classes. Because all information is already in the objects and in the descriptors, we do not consider this as a solution. The only thing we need is to tell OJB not to include every column in the update statement (respectively which columns to include, similar to a ReportQuery). How to do this? Thanks in advance, Norbert. - 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]
OJB (RC4) does not run with Bea Weblogic 8.1
Hello, after my last question here, i considered to change my application to run with OJB rc4. Even the application runs with Bea 6.1 it wont with the Bea 8.1 :-( Did we something wrong? Or has something dramatically changed? Again: The Application without Bea runs fine also under Bea 6.1. Please help. Greetings Ralf The Stacktrace: [org.apache.ojb.broker.accesslayer.ConnectionManagerFactory] ERROR: ConfigurableFactory instantiation failed for class class org.apache.ojb.broker.acce sslayer.ConnectionManagerImpl * Factory types: 1 - Type: org.apache.ojb.broker.PersistenceBroker * Factory arguments: 1 - Argument: [EMAIL PROTECTED] null java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:274) at org.apache.ojb.broker.util.ClassHelper.newInstance(Unknown Source) at org.apache.ojb.broker.util.factory.ConfigurableFactory.createNewInstance(Unknown Source) at org.apache.ojb.broker.util.factory.ConfigurableFactory.createNewInstance(Unknown Source) at org.apache.ojb.broker.accesslayer.ConnectionManagerFactory.createConnectionManager(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.init(Unknown Source) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:274) at org.apache.ojb.broker.util.ClassHelper.newInstance(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl.createNewBrokerInstance(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl$PBKeyedPoolableObjectFactory.makeObject(Unknown Source) at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl.createPersistenceBroker(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl.createPersistenceBroker(Unknown Source) at org.apache.ojb.broker.PersistenceBrokerFactory.createPersistenceBroker(Unknown Source) at de.intersoft.persil.appservertest.BrokerFabrik.makeBroker(BrokerFabrik.java:45) at de.intersoft.persil.appservertest.SchemaAccountTest.testSchemaRead(SchemaAccountTest.java:79) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.textui.TestRunner.doRun(TestRunner.java:116) at junit.textui.TestRunner.doRun(TestRunner.java:109) at junit.textui.TestRunner.run(TestRunner.java:72) at de.intersoft.persil.appservertest.SteuerungsServlet.testConcurrentAccount(SteuerungsServlet.java:85) at de.intersoft.persil.appservertest.SteuerungsServlet.service(SteuerungsServlet.java:60) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1053) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:387) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6291) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:97) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3575) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2573) at
RE: Choose columns to update
Hi Ron, thanks for your reply. Setting the access property is not suitable, because for each modification a client does, we have to update one record, and insert another one. The update touches only 2 fields. The insert naturally has to write all fields. Could be solved with 2 descriptors on the same table. But this behaviour is generic for all our 80 tables. If we find a generic solution, we could save a lot of 'useless' code. Somehow the best solution would be if OJB includes only those attributes in the update query which indeed were changed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 09. Oktober 2003 14:19 To: [EMAIL PROTECTED] Subject: RE: Choose columns to update Norbert -- As far as excluding certain columns from an insert/update statement, setting the 'access' property on an field-descriptor to 'readonly' will cause that field/column to be excluded from any insert/update statement that is generated by ojb. As far as getting OJB to issue an insert statement in lieu of an update statement, the PersistenceBroker interface defines two methods for storing objects: public void store(Object obj); public void store(Object obj, ObjectModification modification); If you call the second version of this method and pass org.apache.ojb.broker.util.ObjectModificationDefaultImpl#INSERT for the 'modification' argument, then ojb will issue an insert statement. Ron Gallagher Atlanta, GA [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 08, 2003 10:13 AM To: [EMAIL PROTECTED] Subject: Choose columns to update Hi all, we use OJB1.0 RC4 against a DB2. We want to tell OJB which columns should be included in the update statement instead of updating all of them. The columns to update have the same name and definition in all the tables. Detailled information: We have tables with many columns. Some columns hold only 'technical' information like lastupdate timestamp and occur in each table. Whenever a record is modified, we *insert* a new one and update these technical attributes of the previously valid record (i.e. we are historizing the changes). The tables also have many indexes. Therefore, updates on all fields are costy (beside the bigger effort to build the query, higher network traffic to the database and the obvious bigger overhead for the database, it seems that these non-affected fields also cause costy index calculations ond the database if incuded in the update). What we actually need would be another descriptor for each table which describes only this subset of columns to update. But this would cause many more descriptors and classes. Because all information is already in the objects and in the descriptors, we do not consider this as a solution. The only thing we need is to tell OJB not to include every column in the update statement (respectively which columns to include, similar to a ReportQuery). How to do this? Thanks in advance, Norbert. - 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: OJB RC4 does not select all objects?
Hi Guido,
On Wed, 08 Oct 2003 18:17:21 +0200, Guido Beutler [EMAIL PROTECTED]
wrote:
Hi Armin,
took some time but I was able to build the testcase.
snip :-)
great!
...
If I run the standalone testcase with eager-release=true
the test fails. Only one object is selected.
If I set eager-release=false everything works fine.
eager-release is the root of all evil :-)
I know it's a workaround for a jboss problem.
What can I do inside of jboss with my ejb's now???
I don't know if this problem is caused by
jboss or by OJB. But I assume it's jboss because
I never heard about problems (with connections) within
e.g. weblogic.
The 'eager-release' attribute was introduced by
Matthew, maybe he can sheed some light on the
problem why jboss needs this special handling.
you said when set eager-release 'false' you get the
following stack trace:
15:59:17,408 INFO [TxConnectionManager$TxConnectionEventListener]
throwable from unregister connection
java.lang.IllegalStateException: Trying to return an unknown connection1!
[EMAIL PROTECTED]
at
org.jboss.resource.connectionmanager.CachedConnectionManager.unregisterConnection(CachedConnectionManager.java:264)
at
org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.connectionClosed(TxConnectionManager.java:550)
...
I looked in the source code of jboss 3.2.1
online source can be found at
http://threebit.net/documentation/doxygen/jboss-3.2.1-src/html/CachedConnectionManager_8java-source.html
http://threebit.net/documentation/doxygen/jboss-3.2.1-src/html/TxConnectionManager_8java-source.html
TxConnectionManager$TxConnectionEventListener.connectionClosed looks
like
public void connectionClosed(ConnectionEvent ce)
00541 {
00542 log.trace(connectionClosed called);
00543 if (this.getManagedConnection() !=
(ManagedConnection)ce.getSource())
00544 {
00545 throw new IllegalArgumentException(ConnectionClosed
event received from wrong ManagedConnection! Expected:
+ this.getManagedConnection() + , actual: + ce.getSource());
00546 } // end of if ()
00547 //log.trace(about to call unregisterConnection);
00548 try
00549 {
00550 getCcm().unregisterConnection(TxConnectionManager.this,
ce.getConnectionHandle()); }
00551 catch (Throwable t)
00552 {
00553 log.info(throwable from unregister connection, t);
00554 } // end of try-catch
00555
...
and CachedConnectionManager.unregisterConnection looks like
00248void unregisterConnection(ConnectionCacheListener cm, Object c)
00249{
00250 KeyConnectionAssociation key = peekMetaAwareObject();
00251 if (log.isTraceEnabled())
00252 {
00253 log.trace(unregistering connection from + cm + ,
object: + c + , key: + key);
00254 } // end of if ()
00255 if (key == null)
00256 {
00257 return; //not participating properly in this management
scheme.
00258 } // end of if ()
00259
00260 Map cmToConnectionsMap = key.getCMToConnectionsMap();
00261 Collection conns = (Collection)cmToConnectionsMap.get(cm);
00262 if (conns == null)
00263 {
00264 throw new IllegalStateException(Trying to return an
unknown connection1! + c);
00265 //return;//???shouldn't happen.
00266 } // end of if ()
00267 for (Iterator i = conns.iterator(); i.hasNext(); )
00268 {
00269 if (((ConnectionRecord)i.next()).connection == c)
...
Looks strange for me to throw an IllegalStateException and then
catch it and log with info-level.
Next strange server log output (when run bean examples) is something like:
2003-10-08 23:22:07,782 DEBUG
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] SQL:INSERT
INTO EJB_ARTICLE (ARTICLE_ID,NAME,PRICE,DESCRIPTION,CATEGORY_ID) VALUES
(?,?,?,?,?)
2003-10-08 23:22:07,782 DEBUG
[org.apache.ojb.broker.accesslayer.JdbcAccessImpl] executeInsert:
[EMAIL PROTECTED]
2003-10-08 23:22:07,782 DEBUG
[org.apache.ojb.broker.accesslayer.StatementManager] closeResources was
called
2003-10-08 23:22:07,782 DEBUG
[org.apache.ojb.broker.core.PersistenceBrokerImpl] PB.close was called:
[EMAIL PROTECTED]
2003-10-08 23:22:07,782 WARN
[org.jboss.resource.adapter.jdbc.WrappedConnection] Closing a statement
you left open, please do your own housekeeping
That's strange, because StatementManager close given statement on
'closeResources' call.
Does OJB internally open another statement and do not close, or do jboss
ignore
the statement close call made by StatementManager?
Any kind of proposal are welcome!
regards,
Armin
best regards,
Guido
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Re: OJB RC4 does not select all objects?
Hi Armin,
just to keep the problem clear:
If I run my standalone tescase (without any jboss around it) and set
eager-release to true the problem occours too!
Only one instead of 77 objects are selected.
If I change to eager-release=false all 77 objects are selected.
best regards,
Guido
Armin Waibel wrote:
Hi Guido,
On Wed, 08 Oct 2003 18:17:21 +0200, Guido Beutler
[EMAIL PROTECTED] wrote:
Hi Armin,
took some time but I was able to build the testcase.
snip :-)
great!
...
If I run the standalone testcase with eager-release=true
the test fails. Only one object is selected.
If I set eager-release=false everything works fine.
eager-release is the root of all evil :-)
I know it's a workaround for a jboss problem.
What can I do inside of jboss with my ejb's now???
I don't know if this problem is caused by
jboss or by OJB. But I assume it's jboss because
I never heard about problems (with connections) within
e.g. weblogic.
The 'eager-release' attribute was introduced by
Matthew, maybe he can sheed some light on the
problem why jboss needs this special handling.
you said when set eager-release 'false' you get the
following stack trace:
15:59:17,408 INFO [TxConnectionManager$TxConnectionEventListener]
throwable from unregister connection
java.lang.IllegalStateException: Trying to return an unknown
connection1! [EMAIL PROTECTED]
at
org.jboss.resource.connectionmanager.CachedConnectionManager.unregisterConnection(CachedConnectionManager.java:264)
at
org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.connectionClosed(TxConnectionManager.java:550)
...
I looked in the source code of jboss 3.2.1
online source can be found at
http://threebit.net/documentation/doxygen/jboss-3.2.1-src/html/CachedConnectionManager_8java-source.html
http://threebit.net/documentation/doxygen/jboss-3.2.1-src/html/TxConnectionManager_8java-source.html
TxConnectionManager$TxConnectionEventListener.connectionClosed looks
like
public void connectionClosed(ConnectionEvent ce)
00541 {
00542 log.trace(connectionClosed called);
00543 if (this.getManagedConnection() !=
(ManagedConnection)ce.getSource())
00544 {
00545 throw new IllegalArgumentException(ConnectionClosed
event received from wrong ManagedConnection! Expected: +
this.getManagedConnection() + , actual: + ce.getSource());
00546 } // end of if ()
00547 //log.trace(about to call unregisterConnection);
00548 try
00549 {
00550
getCcm().unregisterConnection(TxConnectionManager.this,
ce.getConnectionHandle()); }
00551 catch (Throwable t)
00552 {
00553 log.info(throwable from unregister connection, t);
00554 } // end of try-catch
00555
...
and CachedConnectionManager.unregisterConnection looks like
00248void unregisterConnection(ConnectionCacheListener cm, Object c)
00249{
00250 KeyConnectionAssociation key = peekMetaAwareObject();
00251 if (log.isTraceEnabled())
00252 {
00253 log.trace(unregistering connection from + cm + ,
object: + c + , key: + key);
00254 } // end of if ()
00255 if (key == null)
00256 {
00257 return; //not participating properly in this management
scheme.
00258 } // end of if ()
00259
00260 Map cmToConnectionsMap = key.getCMToConnectionsMap();
00261 Collection conns = (Collection)cmToConnectionsMap.get(cm);
00262 if (conns == null)
00263 {
00264 throw new IllegalStateException(Trying to return an
unknown connection1! + c);
00265 //return;//???shouldn't happen.
00266 } // end of if ()
00267 for (Iterator i = conns.iterator(); i.hasNext(); )
00268 {
00269 if (((ConnectionRecord)i.next()).connection == c)
...
Looks strange for me to throw an IllegalStateException and then
catch it and log with info-level.
Next strange server log output (when run bean examples) is something
like:
2003-10-08 23:22:07,782 DEBUG
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl]
SQL:INSERT INTO EJB_ARTICLE
(ARTICLE_ID,NAME,PRICE,DESCRIPTION,CATEGORY_ID) VALUES (?,?,?,?,?)
2003-10-08 23:22:07,782 DEBUG
[org.apache.ojb.broker.accesslayer.JdbcAccessImpl] executeInsert:
[EMAIL PROTECTED]
2003-10-08 23:22:07,782 DEBUG
[org.apache.ojb.broker.accesslayer.StatementManager] closeResources
was called
2003-10-08 23:22:07,782 DEBUG
[org.apache.ojb.broker.core.PersistenceBrokerImpl] PB.close was
called: [EMAIL PROTECTED]
2003-10-08 23:22:07,782 WARN
[org.jboss.resource.adapter.jdbc.WrappedConnection] Closing a
statement you left open, please do your own housekeeping
That's strange, because StatementManager close given statement on
'closeResources' call.
Does OJB internally open another statement and do not close, or do
jboss ignore
the statement close call made by StatementManager?
Any kind of proposal are welcome!
regards,
RE: Choose columns to update
Norbert -- Have you considered utilizing the stored procedure support that's now available on OJB? For each table, you would simply rely on the 'standard' OJB logic for handling insert and delete operations. For update operations, you would set up an update-procedure descriptor that identifies the stored procedure that would handle the update operation. In this stored procedure, you would do exactly what you describe below: Update the existing record as necessary and create a new record. Since the same pattern applies to all 80 tables, you could probably set up some sort of code generation process to create the update procedures for each of the 80 tables. Just a thought. Ron Gallagher Atlanta, GA [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, October 09, 2003 8:37 AM To: [EMAIL PROTECTED] Subject: RE: Choose columns to update Hi Ron, thanks for your reply. Setting the access property is not suitable, because for each modification a client does, we have to update one record, and insert another one. The update touches only 2 fields. The insert naturally has to write all fields. Could be solved with 2 descriptors on the same table. But this behaviour is generic for all our 80 tables. If we find a generic solution, we could save a lot of 'useless' code. Somehow the best solution would be if OJB includes only those attributes in the update query which indeed were changed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 09. Oktober 2003 14:19 To: [EMAIL PROTECTED] Subject: RE: Choose columns to update Norbert -- As far as excluding certain columns from an insert/update statement, setting the 'access' property on an field-descriptor to 'readonly' will cause that field/column to be excluded from any insert/update statement that is generated by ojb. As far as getting OJB to issue an insert statement in lieu of an update statement, the PersistenceBroker interface defines two methods for storing objects: public void store(Object obj); public void store(Object obj, ObjectModification modification); If you call the second version of this method and pass org.apache.ojb.broker.util.ObjectModificationDefaultImpl#INSERT for the 'modification' argument, then ojb will issue an insert statement. Ron Gallagher Atlanta, GA [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 08, 2003 10:13 AM To: [EMAIL PROTECTED] Subject: Choose columns to update Hi all, we use OJB1.0 RC4 against a DB2. We want to tell OJB which columns should be included in the update statement instead of updating all of them. The columns to update have the same name and definition in all the tables. Detailled information: We have tables with many columns. Some columns hold only 'technical' information like lastupdate timestamp and occur in each table. Whenever a record is modified, we *insert* a new one and update these technical attributes of the previously valid record (i.e. we are historizing the changes). The tables also have many indexes. Therefore, updates on all fields are costy (beside the bigger effort to build the query, higher network traffic to the database and the obvious bigger overhead for the database, it seems that these non-affected fields also cause costy index calculations ond the database if incuded in the update). What we actually need would be another descriptor for each table which describes only this subset of columns to update. But this would cause many more descriptors and classes. Because all information is already in the objects and in the descriptors, we do not consider this as a solution. The only thing we need is to tell OJB not to include every column in the update statement (respectively which columns to include, similar to a ReportQuery). How to do this? Thanks in advance, Norbert. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Too many database queries
Hello! I'm new to OJB and need some help! I try to fill a a ui table using the PBAPI. The table is has the following structure: ++-+---+---. . ++ Article.class + Article.class + Art. ++=+===+===. + SalesPerson.class +null + Price.class +Pri ++-+---+--- + SalesPerson.class +Price.class + null+Pri ++-+---+--- . Artikel 1* Price SalesPerson 1* Price At the moment I query at first the articles, 2th the sales persons, and after that, I query each price by its xy-coordinate to find the related article and sales person. On smale tables( 4, 10), it works fine, but on larger tables the performance is not acceptable. Is it possible to create a Query which create such a matrix with ordered columns by articleNo and ordered rows by sales person's name at ones? Best regards, Andreas The content of this e-mail is only meant for the designated addressee and has to be kept in confidence. Please inform us by return if you are not the meant addressee and after that please delete the received e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antwort: [Fwd: SQLGenerator]
Thank you, This solved the problem. Giora [EMAIL PROTECTED] 10/09/2003 03:12 AM Please respond to OJB Users List To: OJB Users List [EMAIL PROTECTED] cc: Subject:Antwort: [Fwd: SQLGenerator] Giora, the elements fk-pointing-to-this-class and fk-pointing-to-element-class must specifiy the foreign key columns in the indirection table, not the primary keys of the linked tables. These fk columns necessarily have different names as the are in the same table. HTH Gerhard Original Message Subject: SQLGenerator Date: Wed, 8 Oct 2003 15:26:40 -0400 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hi Thomas. My name is Giora. I am using OJB (Love it). In my repository I have the following mapping for a collection using m:n without decomposition: collection-descriptor name=children collection-class=org.apache.ojb.odmg.collections.DListImpl element-class-ref=com.bony.framework.acl.dao.GroupDAO proxy=true auto-retrieve=true auto-update=false auto-delete=false indirection-table=A_GTM_REL_GRP fk-pointing-to-this-class column=GRP_REF_ID/ fk-pointing-to-element-class column=GRP_REF_ID/ /collection-descriptor Since both table use the GRP_REF_ID column name OJB generates SQL without fully qualifying the column names. The result is the following exception: The column GRP_REF_ID is specified more than once in the INSERT, UPDATE or SET transition-variable statement. SQLSTATE=42701. Is there any way to instruct OJB to pre append the table alias to the column name? Thank you, Giora - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although The Bank of New York attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses.
Re: ConcurrentModificationException
To be really careful about closing the broker, you may want to include a try/finally
structure. Here is Charles' code modified:
public void onEvent() {
PersistenceBroker pb = PersistenceBrokerFactory.defaultPersistenceBroker();
try {
pb.store(this); // or whatever it is you want to do with the broker
} finally {
pb.close();
}
}
Charles Anthony [EMAIL PROTECTED] wrote:
Hi,
You need to ensure that you are closing the broker.
public void onEvent(){
PersistenceBroker pb =
PersistenceBrokerFactory.defaultPersistenceBroker();
pb.store(this); // or whatever it is you want to do with the broker
pb.close();
}
You should only get brokers when you need them, and close them when you've
finished with them.
HTH,
Charles.
-Original Message-
From: Michael Watson [mailto:[EMAIL PROTECTED]
Sent: 09 October 2003 12:53
To: OJB Users List; [EMAIL PROTECTED]
Subject: Re: ConcurrentModificationException
Hi Armin,
I have an object with an init method where I assign a
PersistenceBroker
instance using
PersistenceBrokerFactory.defaultPersistenceBroker()
This object then has an onEvent() method that is called and uses
broker.store().
I tried modifying the object so that the broker is obtained
in the onEvent
instead of the init and I started getting
Borrow broker from pool failed Exceptions. I have my
connection-pool set
up as follows:
connection-pool maxActive=-1 whenExhaustedAction=2
validationQuery=select 1 from t_client/
Do you have any suggestions for what I might be doing wrong?
Mike
- Original Message -
From: Armin Waibel [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]
Sent: Wednesday, October 08, 2003 6:02 PM
Subject: Re: ConcurrentModificationException
Hi Michael,
On Wed, 8 Oct 2003 17:31:15 +0100, Michael Watson
[EMAIL PROTECTED] wrote:
Hi all,
I'm finding I quite reguarly get this exception when I'm
attempting to
call
PersistenceBroker.store(Object) from multiple threads
simultaneously.
Do several threads share the same PB instance?
If so, this is not allowed. PB instances are not
threadsafe itself, but they are pooled so it's no
performance impact to use a separate PB instance for each thread.
regards,
Armin
?xml version='1.0'?
exception
cause
detailMessage/
exceptionClassjava.util.ConcurrentModificationException/exc
eptionClass
stackTrace
stackTracejava.util.AbstractList$Itr.checkForComodification(
AbstractList.j
ava:444)/stackTrace
stackTracejava.util.AbstractList$Itr.next(AbstractList.java:
417)/stackTra
ce
stackTracejava.util.AbstractCollection.remove(AbstractCollec
tion.java:250)
/stackTrace
stackTraceorg.apache.ojb.broker.core.PersistenceBrokerImpl.s
tore(Unknown
Source)/stackTrace
stackTraceorg.apache.ojb.broker.core.PersistenceBrokerImpl.s
tore(Unknown
Source)/stackTrace
stackTraceorg.apache.ojb.broker.core.DelegatingPersistenceBr
oker.store(Unk
nown Source)/stackTrace
...
/stackTrace
/cause
detailMessageFailed to update History record
java.util.ConcurrentModificationException/detailMessage
exceptionClassorg.apache.ojb.broker.PersistenceBrokerExcepti
on/exceptionC
lass
stackTrace/
/exception
Obviously somewhere in the broker there's been an attempt
to modify the
structure of a list by 2 or more threads simultaneously.
My question is, has anything been done to prevent this in a newer
version or
should I just catch these exceptions and retry the store?
I'm using ojb-1.0.rc3 at the moment.
Regards,
Mike
-
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]
This email and any attachments are strictly confidential and are intended
solely for the addressee. If you are not the intended recipient you must
not disclose, forward, copy or take any action in reliance on this message
or its attachments. If you have received this email in error please notify
the sender as soon as possible and delete it from your computer systems.
Any views or opinions presented are solely those of the author and do not
necessarily reflect those of HPD Software Limited or its affiliates.
At present the integrity of email across the internet cannot be guaranteed
and messages sent via this
Re: ConcurrentModificationException
Thanks, that's exactly the approach I'd taken and it works fine.
- Original Message -
From: Justis Peters [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]
Sent: Thursday, October 09, 2003 4:22 PM
Subject: Re: ConcurrentModificationException
To be really careful about closing the broker, you may want to include a
try/finally structure. Here is Charles' code modified:
public void onEvent() {
PersistenceBroker pb =
PersistenceBrokerFactory.defaultPersistenceBroker();
try {
pb.store(this); // or whatever it is you want to do with the
broker
} finally {
pb.close();
}
}
Charles Anthony [EMAIL PROTECTED] wrote:
Hi,
You need to ensure that you are closing the broker.
public void onEvent(){
PersistenceBroker pb =
PersistenceBrokerFactory.defaultPersistenceBroker();
pb.store(this); // or whatever it is you want to do with the broker
pb.close();
}
You should only get brokers when you need them, and close them when
you've
finished with them.
HTH,
Charles.
-Original Message-
From: Michael Watson [mailto:[EMAIL PROTECTED]
Sent: 09 October 2003 12:53
To: OJB Users List; [EMAIL PROTECTED]
Subject: Re: ConcurrentModificationException
Hi Armin,
I have an object with an init method where I assign a
PersistenceBroker
instance using
PersistenceBrokerFactory.defaultPersistenceBroker()
This object then has an onEvent() method that is called and uses
broker.store().
I tried modifying the object so that the broker is obtained
in the onEvent
instead of the init and I started getting
Borrow broker from pool failed Exceptions. I have my
connection-pool set
up as follows:
connection-pool maxActive=-1 whenExhaustedAction=2
validationQuery=select 1 from t_client/
Do you have any suggestions for what I might be doing wrong?
Mike
- Original Message -
From: Armin Waibel [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]
Sent: Wednesday, October 08, 2003 6:02 PM
Subject: Re: ConcurrentModificationException
Hi Michael,
On Wed, 8 Oct 2003 17:31:15 +0100, Michael Watson
[EMAIL PROTECTED] wrote:
Hi all,
I'm finding I quite reguarly get this exception when I'm
attempting to
call
PersistenceBroker.store(Object) from multiple threads
simultaneously.
Do several threads share the same PB instance?
If so, this is not allowed. PB instances are not
threadsafe itself, but they are pooled so it's no
performance impact to use a separate PB instance for each thread.
regards,
Armin
?xml version='1.0'?
exception
cause
detailMessage/
exceptionClassjava.util.ConcurrentModificationException/exc
eptionClass
stackTrace
stackTracejava.util.AbstractList$Itr.checkForComodification(
AbstractList.j
ava:444)/stackTrace
stackTracejava.util.AbstractList$Itr.next(AbstractList.java:
417)/stackTra
ce
stackTracejava.util.AbstractCollection.remove(AbstractCollec
tion.java:250)
/stackTrace
stackTraceorg.apache.ojb.broker.core.PersistenceBrokerImpl.s
tore(Unknown
Source)/stackTrace
stackTraceorg.apache.ojb.broker.core.PersistenceBrokerImpl.s
tore(Unknown
Source)/stackTrace
stackTraceorg.apache.ojb.broker.core.DelegatingPersistenceBr
oker.store(Unk
nown Source)/stackTrace
...
/stackTrace
/cause
detailMessageFailed to update History record
java.util.ConcurrentModificationException/detailMessage
exceptionClassorg.apache.ojb.broker.PersistenceBrokerExcepti
on/exceptionC
lass
stackTrace/
/exception
Obviously somewhere in the broker there's been an attempt
to modify the
structure of a list by 2 or more threads simultaneously.
My question is, has anything been done to prevent this in a newer
version or
should I just catch these exceptions and retry the store?
I'm using ojb-1.0.rc3 at the moment.
Regards,
Mike
-
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]
This email and any attachments are strictly confidential and are
intended
solely for the addressee. If you are not the intended recipient you must
not disclose, forward, copy or take any action in reliance on this
message
Re: Choose columns to update
Hi, don't know if this will help you. With MetadataManager you can handle different metadata repositories (on per thread base), thus it's possible to have different ClassDescriptor for the same class (e.g. one with all fields, one with special fields). regards, Armin On Thu, 9 Oct 2003 13:07:10 +0200, [EMAIL PROTECTED] wrote: Thanks for your reply. Could you please give me a hint how to achieve this anyhow? We're planning a dirty workaround: Having a class with a static method called by PersistenceBroker store(Object, ObjectModification) after retrieving the class descriptor. That method clones and modifies the affected class descriptor as desired, depending on the object processed. The risk: If somewhere in the framework the class descriptor is not passed as parameter but instead looked up from the repository again, we're lost. How safe is this approach? Any other idea is highly appreciated. Thanks, Norbert. -Original Message- From: Charles Anthony [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 09. Oktober 2003 12:04 To: 'OJB Users List' Subject: RE: Choose columns to update -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 09 October 2003 11:01 To: [EMAIL PROTECTED] Subject: Choose columns to update Hi all, I need to tell OJB which columns to update when persisting an object (instead of updating all mapped fields). Can anybody please tell me how to do this? Hi, I'm sorry no-one replied before. In short, this is not currently possible with OJB. I have a sneaking suspicion that this is *not* a trivial thing to do; as you may have noticed from the list, the developers are currently trying to work towards a 1.0 release in the near future (maybe via an rc5) - such a substantial feature request would be unlikely to make into a release in the near future. Of course, I may be talking complete rubbish - in which case one of the committers should respond - but I thought I'd reply just so you don't think we are ignoring you on purpose. Cheers, Charles. This email and any attachments are strictly confidential and are intended solely for the addressee. If you are not the intended recipient you must not disclose, forward, copy or take any action in reliance on this message or its attachments. If you have received this email in error please notify the sender as soon as possible and delete it from your computer systems. Any views or opinions presented are solely those of the author and do not necessarily reflect those of HPD Software Limited or its affiliates. At present the integrity of email across the internet cannot be guaranteed and messages sent via this medium are potentially at risk. All liability is excluded to the extent permitted by law for any claims arising as a re- sult of the use of this medium to transmit information by or to HPD Software Limited or its affiliates. - 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: Query returns only identical instances
Hi Cesar, could elaborate on your answer, please? It is absolutely unclear for me what you mean by your answer. I figured that you meant that there was no primary key definded for the table. This was really the case. But changing this fact unfortunately did not help. Did you mean something else? Best regards, Martin. This problem happened with me I had forgotten to a field as primary-key [ ]´s - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 4:19 PM Subject: Query returns only identical instances Hi everyone, I'm absolutely puzzled by the following problem: if I execute a query with field vorgangsnummer as criteria, like this: Criteria lCriteria = new Criteria(); lCriteria.addEqualTo(vorgangsnummer, new Long(pVorgangsnummer)); Query lQuery = new QueryByCriteria(Data.class, lCriteria); Collection lResult = getBroker().getCollectionByQuery(lQuery); , I get a collection filled with identical objects that's count is as high as the count of records for this query. In repository.xml the mapping is defined as follows: class-descriptor class=org.my.company.Data table=daten isolation=read-uncomitted field-descriptor name=vorgangsnummer column=vorgangsnummer jdbc-type=BIGINT/ field-descriptor n ame=nutzer column=nutzer jdbc-type=INTEGER nullable=false/ field-descriptor name=meldungsTyp column=meldungstyp jdbc-type=VARCHAR nullable=false primarykey=true/ field-descriptor name=auftragsNr column=auftrags_nr jdbc-type=BIGINT nullable=false primarykey=true/ /class-descriptor I'm leaving out some fields. The really interesting thing is that if I define 'jdbc-type' as INTEGER for field 'auftragsNr' the returned objects are absolutely okay. So for example instead of getting ten times the same instance of 'Data' I get ten different instances representing the ten different records from the table 'daten'. The Java type in class 'Data' is declared as long. The records only differ in the values of the field 'auftragsNr'. I am using an Oracle-DBMS. From searching the archives I have seen similar problems occuring when using JBoss. This is not the case here. I'm running a standalone application. Any ideas? Regards, Martin. -- NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
odmg/caching problem?
Hello,
I got the following small program (snippet):
Customer customer=new Customer(no, one, here, 0, , 2, null);
tx = odmg.newTransaction();
tx.begin();
db.makePersistent(new Certificate(Z1\n, customer));
db.makePersistent(customer);
tx.commit();
DList allProducts = (DList) query.execute();
Iterator iter = allProducts.iterator();
while (iter.hasNext())
{
customer=(Customer)iter.next();
System.out.println(customer.getBenutzername() + : +
customer.getCertificates().size());
}
I think the Details don't matter: One Customer can have many Certificates
(1:n relationsship, navigatable in both directions here).
Now the Problem:
The Certificate created for the Customer is NOT listed in the first run of
the program, output:
1065740029439: 0
done!
When running the program for a second time, the records created in the
first run are read correctly, output this time:
1065740029439: 1
1065740078144: 0
done!
... and so on.
Anyone any clues?
Thanks a lot,
-Gunnar
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: odmg/caching problem?
Additional Detail:
Bothe the customer and the certificate are available when being created,
only the relation (Collection) of the newly created customer is not
updated when querying ...
Hello,
I got the following small program (snippet):
Customer customer=new Customer(no, one, here, 0, , 2, null);
tx = odmg.newTransaction();
tx.begin();
db.makePersistent(new Certificate(Z1\n, customer));
db.makePersistent(customer);
tx.commit();
DList allProducts = (DList) query.execute();
Iterator iter = allProducts.iterator();
while (iter.hasNext())
{
customer=(Customer)iter.next();
System.out.println(customer.getBenutzername() + : +
customer.getCertificates().size());
}
I think the Details don't matter: One Customer can have many Certificates
(1:n relationsship, navigatable in both directions here).
Now the Problem:
The Certificate created for the Customer is NOT listed in the first run of
the program, output:
1065740029439: 0
done!
When running the program for a second time, the records created in the
first run are read correctly, output this time:
1065740029439: 1
1065740078144: 0
done!
... and so on.
Anyone any clues?
Thanks a lot,
-Gunnar
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: odmg/caching problem?
Have u added the certificate to the customer? Could not see that from code
posted.
Shane
-Original Message-
From: Gunnar Hilling [mailto:[EMAIL PROTECTED]
Sent: Friday, 10 October 2003 1:28 p.m.
To: [EMAIL PROTECTED]
Subject: Re: odmg/caching problem?
Additional Detail:
Bothe the customer and the certificate are available when being created,
only the relation (Collection) of the newly created customer is not
updated when querying ...
Hello,
I got the following small program (snippet):
Customer customer=new Customer(no, one, here, 0, , 2,
null);
tx = odmg.newTransaction();
tx.begin();
db.makePersistent(new Certificate(Z1\n, customer));
db.makePersistent(customer);
tx.commit();
DList allProducts = (DList) query.execute();
Iterator iter = allProducts.iterator();
while (iter.hasNext())
{
customer=(Customer)iter.next();
System.out.println(customer.getBenutzername() + : +
customer.getCertificates().size());
}
I think the Details don't matter: One Customer can have many
Certificates
(1:n relationsship, navigatable in both directions here).
Now the Problem:
The Certificate created for the Customer is NOT listed in the first run
of
the program, output:
1065740029439: 0
done!
When running the program for a second time, the records created in the
first run are read correctly, output this time:
1065740029439: 1
1065740078144: 0
done!
... and so on.
Anyone any clues?
Thanks a lot,
-Gunnar
-
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: odmg/caching problem?
-Original Message- From: Gunnar Hilling [mailto:[EMAIL PROTECTED] Shane said: By using the auto-insert/update settings and the PersistenceBroker I get what I expect. So far this is also working with odmg in my test (in the given code example I'm persisting the Certificate-Object implicit: customer.addCertificate(certificate); without persisting certificate using db.makePersistant Has that customer already been persisted or was that the first time? Shane - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: odmg/caching problem?
You are right, OJB supports ODMG's persistence by reachability: you
just have to add new or already persisted objects to the DList of your
root object, and its persistence will be handled transparently.
Anyway, you should theoretically place your read query in a transaction
context to check your results:
tx.begin();// --
DList allProducts = (DList) query.execute();
Iterator iter = allProducts.iterator();
while (iter.hasNext())
{
customer=(Customer)iter.next();
System.out.println(customer.getBenutzername() + : +
customer.getCertificates().size());
}
tx.commit();// --
I always place all read or write accesses in a transaction context, and
everything goes fine.
I guess results should be right if the write and the read accesses would
be in the same transaction context, too.
HTH
Gunnar Hilling wrote:
On Fri, 10 Oct 2003 14:03:05 +1300, Shane Mingins wrote:
By using the auto-insert/update settings and the PersistenceBroker I get
what I expect.
So far this is also working with odmg in my test (in the given code
example I'm persisting the Certificate-Object implicit:
customer.addCertificate(certificate);
without persisting certificate using db.makePersistant
Anyway as I have mentioned my experience is not vast so I would defer to
expert advice/opinion :-)
-
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: Choose columns to update
Hi, Have you try to simply duplicate class descriptor : class-descriptor class=A table=A refresh=true field-descriptor id=1 name=id column=ID jdbc-type=BIGINT primarykey=true autoincrement=true/ field-descriptor id=2 name=field2 column=field2 jdbc-type=BIGINT access=readwrite/ field-descriptor id=3 name=field3 column=field3 jdbc-type=VARCHAR access=readwrite/ field-descriptor id=4 name=field4 column=field4 jdbc-type=BIGINT access=readonly/ field-descriptor id=5 name=field5 column=field5 jdbc-type=VARCHAR access=readonly/ ... /class-descriptor used to materialize A objects and so, call your store methode on it after update attribute like this : instanceOfA.setField1(...); instanceOfA.setField2(...); pb.store(instanceOfA); class-descriptor class=AforInsert table=A field-descriptor id=1 name=id column=ID jdbc-type=BIGINT primarykey=true autoincrement=true/ field-descriptor id=2 name=field2 column=field2 jdbc-type=BIGINT access=readwrite/ field-descriptor id=3 name=field3 column=field3 jdbc-type=VARCHAR access=readwrite/ field-descriptor id=4 name=field4 column=field4 jdbc-type=BIGINT access=readwrite/ field-descriptor id=5 name=field5 column=field5 jdbc-type=VARCHAR access=readwrite/ ... /class-descriptor used to create A objects like this : instanceOfA=new AforInsert(field1,field2,field3 ...) pb.store(instanceOfA); - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 09, 2003 2:37 PM Subject: RE: Choose columns to update Hi Ron, thanks for your reply. Setting the access property is not suitable, because for each modification a client does, we have to update one record, and insert another one. The update touches only 2 fields. The insert naturally has to write all fields. Could be solved with 2 descriptors on the same table. But this behaviour is generic for all our 80 tables. If we find a generic solution, we could save a lot of 'useless' code. Somehow the best solution would be if OJB includes only those attributes in the update query which indeed were changed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 09. Oktober 2003 14:19 To: [EMAIL PROTECTED] Subject: RE: Choose columns to update Norbert -- As far as excluding certain columns from an insert/update statement, setting the 'access' property on an field-descriptor to 'readonly' will cause that field/column to be excluded from any insert/update statement that is generated by ojb. As far as getting OJB to issue an insert statement in lieu of an update statement, the PersistenceBroker interface defines two methods for storing objects: public void store(Object obj); public void store(Object obj, ObjectModification modification); If you call the second version of this method and pass org.apache.ojb.broker.util.ObjectModificationDefaultImpl#INSERT for the 'modification' argument, then ojb will issue an insert statement. Ron Gallagher Atlanta, GA [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 08, 2003 10:13 AM To: [EMAIL PROTECTED] Subject: Choose columns to update Hi all, we use OJB1.0 RC4 against a DB2. We want to tell OJB which columns should be included in the update statement instead of updating all of them. The columns to update have the same name and definition in all the tables. Detailled information: We have tables with many columns. Some columns hold only 'technical' information like lastupdate timestamp and occur in each table. Whenever a record is modified, we *insert* a new one and update these technical attributes of the previously valid record (i.e. we are historizing the changes). The tables also have many indexes. Therefore, updates on all fields are costy (beside the bigger effort to build the query, higher network traffic to the database and the obvious bigger overhead for the database, it seems that these non-affected fields also cause costy index calculations ond the database if incuded in the update). What we actually need would be another descriptor for each table which describes only this subset of columns to update. But this would cause many more descriptors and classes. Because all information is already in the objects and in the descriptors, we do not consider this as a solution. The only thing we need is to tell OJB not to include every column in the update statement (respectively which columns to include, similar to a ReportQuery). How to do this? Thanks in advance, Norbert. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL
