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
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]
RE: problems with batch-mode=true
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
org.apache.ojb.broker.core.PersistenceBrokerImpl.abortTransaction(Unknown
Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.abortTransaction(Unkn
own Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.abortTransaction(Unkn
own Source)
at
com.mobius.activebill.dbmigrationutils.CustomerMigration.main(CustomerMigrat
ion.java:75)
Exception in thread "main"
It looks like the persistence broker is being closed down before the call
to abortTransaction
is made. But that does not explain the first exception. This code works
perfectly with
batch-mode="false".
And, if I call executeBatch, I don't get the second exception (the one
about not being in
a transaction), although I still get the first transaction.
I am includ
How to use alias in OQL and how to query two or more tables with ODMG API?
Hi,
I am a newbie in OJB and an now trying the OJB using the ODMG API. I run the
tutorials on the OJB website successfully. But when I am trying one of my
own project, I was stuck in two problems,
1)
for the query string, if I use "select p from Project where companyCode = $1
and billingCode= $2;" everything is fine. But if I am trying to use the
alias for the object, replacing the above query with "select p from Project
p where p.companyCode = $1 and p.billingCode= $2;" there will be exception
thownn,
line 1: unexpected token: p
java.lang.NullPointerException
.
The following is the code.
public Project locateProjectByCodes(String company_code, String
billing_code)
{
String oqlQuery = "select p from Project where companyCode = $1 and
billingCode= $2";
Database db = odmg.getDatabase(null); // the current DB
Transaction tx = null;
Project oneInstance=null;
try
{
// 3. open transaction
tx = odmg.newTransaction();
tx.begin();
// 4. acquire write lock on new object
OQLQuery query = odmg.newOQLQuery();
try
{
query.create(oqlQuery);
System.err.println("finished creating query");
}
catch(QueryInvalidException e)
{
System.err.println("query problem!");
}
query.bind(company_code);
query.bind(billing_code);
DList result = (DList) query.execute();
java.util.Iterator iter = result.iterator();
// 5. commit transaction
tx.commit();
//6. loop the result collection
if (iter.hasNext())
{
oneInstance = (Project) result.get(0);
}
logger.warn("locateProjectByCodes: "+oneInstance.getCompanyCode());
}
catch( Exception e )
{
System.err.println(e.toString());
tx.abort();
e.printStackTrace();
// e.printStackTrace(logger);
// Code omitted for tutorial brevity
}
return null;
}
2) how to query two or more tables? Like the above example, say I have a
table Employee (to simplify the question, we assume it is 1:1 relationship
between these two tables, each employee works on one project)and I want to
get the project information a specified employee works on. With sql, I would
write as "select p.* from Project p, Employee e where
p.ProjectId=e.ProjectId and e.EmployeeName='me'", but how to do this with
ODMG query? I read all the tutorials and more than one examples on internet,
but all of them only query one table each time... In fact, when I tried to
write the OQL, like the above example, the exception reported my second
table name as unexpected token.
Thank you and I am waiting in such eagerness for your help.
Best,
Jack
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
new url for scarab
hi, scarab seems to have moved to http://issues.apache.org/scarab/servlet/scarab/ jakob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JDO - newObjectIdInstance() method failed
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.(GZIPInputStream.java:57) at java.util.zip.GZIPInputStream.(GZIPInputStream.java:67) at org.apache.ojb.broker.Identity.fromByteArray(Unknown Source) at org.apache.ojb.jdori.sql.OjbStoreManager.newObjectIdInstance(Unknown Source) at com.sun.jdori.common.PersistenceManagerImpl.newObjectIdInstance(Unknown Source) at com.sun.jdori.common.PersistenceManagerWrapper.newObjectIdInstance(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(Unknown Source) at com.sun.jdori.common.PersistenceManagerImpl.newObjectIdInstance(Unknown Source) at com.sun.jdori.common.PersistenceManagerWrapper.newObjectIdInstance(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.(GZIPInputStream.java:57) at java.util.zip.GZIPInputStream.(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]
Re: Proxies && 1:1 optional doesn't work?
Yes, I've done all the tests, and really doesn't work. If someone need to use 1:1 optional (or 1:0..1), cannot use proxy. But it's not a lose performance scenario (at least for me), since it's 1:0..1 only... If someone could double check it, please do... It's a boring bug that can affect others trying to use proxies with 1:0..1 mappings. Best regards, Edson Richter - Original Message - From: Edson Carlos Ericksson Richter To: 'OJB Users List' Sent: Friday, October 24, 2003 6:17 PM Subject: Proxies && 1:1 optional doesn't work? Hi! I'm using RC4 CVS Head (I get the source today, at 18:00 GMT-3). Look sample bellow. If I make OutrasInformacoes dynamic proxy, I get an error (method getXxx in object null) if Pessoa hasn't a db record in TB_OUTRAS_INFORMACOES. Also, where there is no OutrasInformacoes em Pessoa, when I use proxy=dynamic for OutrasInformacoes, executing pessoa.getOutrasInformacoes==null results in false (in real, it's a proxy, so it isn't null). But if there is no record, it shouldn't be a proxy. This should be just null. If I remove "proxy=dynamic" line, the every thing works fine. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.530 / Virus Database: 325 - Release Date: 22/10/2003 - 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]
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)) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: OT Crap Signature : Was RE: problem with PB instances creation
Charles, Ok sorry to rag on you. I know all about stupid decisions that are out of my hands I doubt there is anyone who doesn't. Have a nice day. Troy -Original Message- From: Charles Anthony [mailto:[EMAIL PROTECTED] Sent: October 27, 2003 10:51 AM To: 'OJB Users List' Subject: OT Crap Signature : Was RE: problem with PB instances creation Hi, I am well aware that my email signature is a) Unwieldy b) Ugly c) Technically dodgy d) A pain in the backside. It is also questionable whether it has any legal significance whatsoever - I am pretty sure it is totaly useless outside the UK. However, I am unable to change it. It is appended on our server by my employer, who will not allow me to remove it - I believe that we have to have it in order to get liability insurance. I have strongly objected, but have given it up as a battle not worth fighting. I submit that the help and contributions I have given on various mailing lists over the last 4 years balances out the crap I have dumped on them. In short - there's not alot I can do about it. Sorry. Charles. > -Original Message- > From: Taillefer, Troy (EXP) [mailto:[EMAIL PROTECTED] > Sent: 27 October 2003 15:34 > To: OJB Users List > Subject: RE: problem with PB instances creation > > > Charles or whoever owns that weird signature, > > This is a little of topic but I find your signature is a > little strange. Email is traveling across a public medium so > if it is unencrypted it is effectively public domain viewable > by anybody sniffing the net (regardless of what laws may > exist). Plus these emails are stored in a publicly viewable > archive so your claim to confidentiality is irrelevant. I > recommend you don't send any information deemed sensitive, > proprietary or confidential through unencrypted email to a > public mailing list. > > > > -Original Message- > From: Charles Anthony [mailto:[EMAIL PROTECTED] > Sent: October 27, 2003 7:03 AM > To: 'OJB Users List' > Subject: RE: problem with PB instances creation > > > Hi, > > > > > Hello, > > > > OK! It is a bit clearer for me, thanks. > > Each time I want to use a broker I should do: > > > > broker = PersistenceBrokerFactory.defaultPersistenceBroker(); > > //I use the broker > > broker.close(); > > > Yes, this is the way it should be done. > > > Is it better to do this EACH time I use the broker or ask for > > a broker one time (when the application start) and close > > after (all) the use? > > It is better to do it each time. > > If this is an "issue" for you, I suggest you look at using > ODMG; it hides > all broker usage from your application. > > > > About the MAX number of broker in OJB.properties, is it a > > good way to set this number to 100 or even 1000? > > > > Finally what is the exact meaning of this 2 log messages: > > "Already created persistence broker instances: x"? > > "Already created connections: 3 returning: ..."? > > > I'm afraid I don't know precisely.. > > Cheers, > > Charles. > > > Thanks for your help > > Sylvain > > > > > > > > > > -Message d'origine- > > De: Charles Anthony [mailto:[EMAIL PROTECTED] > > Date: lundi, 27. octobre 2003 11:27 > > À: 'OJB Users List' > > Objet: RE: problem with PB instances creation > > > > > > Hi, > > > > at line 27, you should repeat lines 9-13. > > > > At line 10 > > PersistenceBrokerFactory.defaultPersistenceBroker() asks the pool > > for a broker, creating one *if* *necessary*. > > broker.close releases some resources from the broker, and > returns the > > broker to the pool. > > > > In other words, after you close the broker, you can no longer > > use it. You > > must get another broker. > > > > If you really need to know how many (active) brokers there > > are in the pool, > > you should be able to do > > > > PersistenceBrokerFactoryDefaultImpl factory = > > (PersistenceBrokerFactoryDefaultImpl) > > PersistenceBrokerFactoryFactory.instance(); > > int brokersInPool = factory.activePersistenceBroker(); > > > > Cheers, > > > > Charles > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > > > Sent: 27 October 2003 10:17 > > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > > Subject: RE: problem with PB instances creation > > > > > > > > > Hello Thomas, > > > > > > Is there a way to check how many instances are contained in > > the pool? > > > > > > You can find an example below. > > > You create a broker instance in line 10, right? > > > You use the broker instance first time in line 19. After this > > > use you close() the instance. > > > But the problem is if you do the close() in line 25 when you > > > use the broker for the second time in line 29 you have a > > > ConnectionNotInProgressException. > > > > > > Do I have to create a second broker? > > > Or do I have to call a broker from the pool? How? > > > > > > Thanks for your help > > > Sylvain > > > > > > > > > 1 public class MyExam
OT Crap Signature : Was RE: problem with PB instances creation
Hi,
I am well aware that my email signature is
a) Unwieldy
b) Ugly
c) Technically dodgy
d) A pain in the backside.
It is also questionable whether it has any legal significance whatsoever - I
am pretty sure it is totaly useless outside the UK.
However, I am unable to change it.
It is appended on our server by my employer, who will not allow me to remove
it - I believe that we have to have it in order to get liability insurance.
I have strongly objected, but have given it up as a battle not worth
fighting.
I submit that the help and contributions I have given on various mailing
lists over the last 4 years balances out the crap I have dumped on them.
In short - there's not alot I can do about it. Sorry.
Charles.
> -Original Message-
> From: Taillefer, Troy (EXP) [mailto:[EMAIL PROTECTED]
> Sent: 27 October 2003 15:34
> To: OJB Users List
> Subject: RE: problem with PB instances creation
>
>
> Charles or whoever owns that weird signature,
>
> This is a little of topic but I find your signature is a
> little strange. Email is traveling across a public medium so
> if it is unencrypted it is effectively public domain viewable
> by anybody sniffing the net (regardless of what laws may
> exist). Plus these emails are stored in a publicly viewable
> archive so your claim to confidentiality is irrelevant. I
> recommend you don't send any information deemed sensitive,
> proprietary or confidential through unencrypted email to a
> public mailing list.
>
>
>
> -Original Message-
> From: Charles Anthony [mailto:[EMAIL PROTECTED]
> Sent: October 27, 2003 7:03 AM
> To: 'OJB Users List'
> Subject: RE: problem with PB instances creation
>
>
> Hi,
>
> >
> > Hello,
> >
> > OK! It is a bit clearer for me, thanks.
> > Each time I want to use a broker I should do:
> >
> > broker = PersistenceBrokerFactory.defaultPersistenceBroker();
> > //I use the broker
> > broker.close();
>
>
> Yes, this is the way it should be done.
>
> > Is it better to do this EACH time I use the broker or ask for
> > a broker one time (when the application start) and close
> > after (all) the use?
>
> It is better to do it each time.
>
> If this is an "issue" for you, I suggest you look at using
> ODMG; it hides
> all broker usage from your application.
>
>
> > About the MAX number of broker in OJB.properties, is it a
> > good way to set this number to 100 or even 1000?
> >
> > Finally what is the exact meaning of this 2 log messages:
> > "Already created persistence broker instances: x"?
> > "Already created connections: 3 returning: ..."?
>
>
> I'm afraid I don't know precisely..
>
> Cheers,
>
> Charles.
>
> > Thanks for your help
> > Sylvain
> >
> >
> >
> >
> > -Message d'origine-
> > De: Charles Anthony [mailto:[EMAIL PROTECTED]
> > Date: lundi, 27. octobre 2003 11:27
> > À: 'OJB Users List'
> > Objet: RE: problem with PB instances creation
> >
> >
> > Hi,
> >
> > at line 27, you should repeat lines 9-13.
> >
> > At line 10
> > PersistenceBrokerFactory.defaultPersistenceBroker() asks the pool
> > for a broker, creating one *if* *necessary*.
> > broker.close releases some resources from the broker, and
> returns the
> > broker to the pool.
> >
> > In other words, after you close the broker, you can no longer
> > use it. You
> > must get another broker.
> >
> > If you really need to know how many (active) brokers there
> > are in the pool,
> > you should be able to do
> >
> > PersistenceBrokerFactoryDefaultImpl factory =
> > (PersistenceBrokerFactoryDefaultImpl)
> > PersistenceBrokerFactoryFactory.instance();
> > int brokersInPool = factory.activePersistenceBroker();
> >
> > Cheers,
> >
> > Charles
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]
> > > Sent: 27 October 2003 10:17
> > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > > Subject: RE: problem with PB instances creation
> > >
> > >
> > > Hello Thomas,
> > >
> > > Is there a way to check how many instances are contained in
> > the pool?
> > >
> > > You can find an example below.
> > > You create a broker instance in line 10, right?
> > > You use the broker instance first time in line 19. After this
> > > use you close() the instance.
> > > But the problem is if you do the close() in line 25 when you
> > > use the broker for the second time in line 29 you have a
> > > ConnectionNotInProgressException.
> > >
> > > Do I have to create a second broker?
> > > Or do I have to call a broker from the pool? How?
> > >
> > > Thanks for your help
> > > Sylvain
> > >
> > >
> > > 1 public class MyExample {
> > > 2
> > > 3 private PersistenceBroker broker;
> > > 4
> > > 5 public void test() {
> > > 6 /**
> > > 7 * Persistence Broker
> > > 8 */
> > > 9 try {
> > > 10broker =
> > > PersistenceBrokerFactory.defaultPersistenceBroker();
> > > 11} catch (Throwable t) {
> > > 12t.printStackTrace();
> > > 13}
> >
RE: problem with PB instances creation
Charles or whoever owns that weird signature,
This is a little of topic but I find your signature is a little strange. Email is
traveling across a public medium so if it is unencrypted it is effectively public
domain viewable by anybody sniffing the net (regardless of what laws may exist). Plus
these emails are stored in a publicly viewable archive so your claim to
confidentiality is irrelevant. I recommend you don't send any information deemed
sensitive, proprietary or confidential through unencrypted email to a public mailing
list.
-Original Message-
From: Charles Anthony [mailto:[EMAIL PROTECTED]
Sent: October 27, 2003 7:03 AM
To: 'OJB Users List'
Subject: RE: problem with PB instances creation
Hi,
>
> Hello,
>
> OK! It is a bit clearer for me, thanks.
> Each time I want to use a broker I should do:
>
> broker = PersistenceBrokerFactory.defaultPersistenceBroker();
> //I use the broker
> broker.close();
Yes, this is the way it should be done.
> Is it better to do this EACH time I use the broker or ask for
> a broker one time (when the application start) and close
> after (all) the use?
It is better to do it each time.
If this is an "issue" for you, I suggest you look at using ODMG; it hides
all broker usage from your application.
> About the MAX number of broker in OJB.properties, is it a
> good way to set this number to 100 or even 1000?
>
> Finally what is the exact meaning of this 2 log messages:
> "Already created persistence broker instances: x"?
> "Already created connections: 3 returning: ..."?
I'm afraid I don't know precisely..
Cheers,
Charles.
> Thanks for your help
> Sylvain
>
>
>
>
> -Message d'origine-
> De: Charles Anthony [mailto:[EMAIL PROTECTED]
> Date: lundi, 27. octobre 2003 11:27
> À: 'OJB Users List'
> Objet: RE: problem with PB instances creation
>
>
> Hi,
>
> at line 27, you should repeat lines 9-13.
>
> At line 10
> PersistenceBrokerFactory.defaultPersistenceBroker() asks the pool
> for a broker, creating one *if* *necessary*.
> broker.close releases some resources from the broker, and returns the
> broker to the pool.
>
> In other words, after you close the broker, you can no longer
> use it. You
> must get another broker.
>
> If you really need to know how many (active) brokers there
> are in the pool,
> you should be able to do
>
> PersistenceBrokerFactoryDefaultImpl factory =
> (PersistenceBrokerFactoryDefaultImpl)
> PersistenceBrokerFactoryFactory.instance();
> int brokersInPool = factory.activePersistenceBroker();
>
> Cheers,
>
> Charles
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> > Sent: 27 October 2003 10:17
> > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Subject: RE: problem with PB instances creation
> >
> >
> > Hello Thomas,
> >
> > Is there a way to check how many instances are contained in
> the pool?
> >
> > You can find an example below.
> > You create a broker instance in line 10, right?
> > You use the broker instance first time in line 19. After this
> > use you close() the instance.
> > But the problem is if you do the close() in line 25 when you
> > use the broker for the second time in line 29 you have a
> > ConnectionNotInProgressException.
> >
> > Do I have to create a second broker?
> > Or do I have to call a broker from the pool? How?
> >
> > Thanks for your help
> > Sylvain
> >
> >
> > 1 public class MyExample {
> > 2
> > 3 private PersistenceBroker broker;
> > 4
> > 5 public void test() {
> > 6 /**
> > 7 * Persistence Broker
> > 8 */
> > 9 try {
> > 10 broker =
> > PersistenceBrokerFactory.defaultPersistenceBroker();
> > 11 } catch (Throwable t) {
> > 12 t.printStackTrace();
> > 13 }
> > 14
> > 15 Criteria crit = new Criteria();
> > 16 ...
> > 17
> > 18 try {
> > 19 broker.beginTransaction();
> > 20 //query 1...
> > 21 broker.commitTransaction();
> > 22 } catch (Throwable t) {
> > 23 broker.abortTransaction();
> > 24 } finally {
> > 25 broker.close();
> > 26 }
> > 27
> > 28 try {
> > 29 broker.beginTransaction();
> > 30 //query 2...
> > 31 broker.commitTransaction();
> > 32 } catch (Throwable t) {
> > 33 broker.abortTransaction();
> > 34 } finally {
> > 35 broker.close();
> > 36 }
> > 37 }
> > 38 }
> >
> >
> > -Message d'origine-
> > De: Thomas Mahler [mailto:[EMAIL PROTECTED]
> > Date: vendredi, 24. octobre 2003 18:17
> > À: OJB Users List
> > Objet: Re: problem with PB instances creation
> >
> >
> > Hi Sylvain,
> >
> > [EMAIL PROTECTED] wrote:
> > > Hello,
> > >
> > > I'm using OJB in my web application and I have some problem
> > with PB instances creation.
> > >
> > > Each time I want to read/write data from/to my database I
> > create a PB intance:
> > > broker = PersistenceBrokerFactory.defaultPersistenceBroker();
> > >
> > > The problem is that lot of PB instances a
RE: Auto incremented primary key and extents
Armin Thanks -- don't suppose you could grab me a CVS head could you if you get the chance... Thanks Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:50 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, Mark Rowell wrote: > Sorry > > After looking at SequenceManaherHelper I know that the max id of > sequence for extent is not... > > More on the batch mode stuff -- I onlt just turned it on and got these > problems. RC4 has been working Prior to setting batch-mode="true" in > the configuration. > hmm, AFAIK Oleg has fixed some bugs in conjunction with batch mode (since rc4). So your problems maybe a side-effect of the bugs in batch-mode. regards, Armin > -Original Message- > From: Mark Rowell [mailto:[EMAIL PROTECTED] > Sent: 27 October 2003 12:25 > To: 'OJB Users List' > Subject: RE: Auto incremented primary key and extents > > > Armin > > No the only thing I changed was OJB.properties. > > One thing is that this problem happened during a run of my application > where some batch mode=true stuff Was used. Would this have an impact? > > Is the sequence max id still stored in OJB_HL_SEQ? > > Regards > > Mark > > -Original Message- > From: Armin Waibel [mailto:[EMAIL PROTECTED] > Sent: 27 October 2003 12:21 > To: OJB Users List > Subject: Re: Auto incremented primary key and extents > > > Hi Mark, > > > But as a follow on the extents are more than one level deep -- > would > this > have an impact? No should not. Have a look in > SequenceManagerHelper#getMaxForExtent > > > > unique Over all tables in the extent? Have I misconfigured OJB on > upgrading > > to RC4? > Did you change metadata on upgrading? Add new extents, > change order of declaration? > > regards, > Armin > > > Mark Rowell wrote: > > >>Sorry >> >>But as a follow on the extents are more than one level deep -- would >>this have an impact? >> >>Regards, >> >>Mark Rowell >> >>-Original Message- >>From: Mark Rowell [mailto:[EMAIL PROTECTED] >>Sent: 27 October 2003 11:30 >>To: '[EMAIL PROTECTED]' >>Subject: Auto incremented primary key and extents >> >> >>Hi >> >>I have an extent over 8 classes (and 8 corresponding tables) and I >>have noticed that primary keys are now not unique over all tables -- >>e.g. when I store and instances of 2 different classes In different >>"leaves" of the extent I get the same ID in both tables. In RC1 I the >>autogenerated IDs were unique Over all tables in the extent? Have I >>misconfigured OJB on upgrading to RC4? >> >>Regards, >> >>Mark Rowell >> >>--- >>Mark Rowell >>Structured Credit Europe >>CreditTrade Limited >>180 Fleet Street >>London EC4A 2HG >> >>Tel +44 (0)20 7400 5078 >>Fax +44 (0)20 7400 5099 >> >>http://www.credittrade.com >> >> >> >>CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All >>rights reserved. The information and data contained in this email is >>provided for the information purposes of the addressee only and should >>not be reproduced and/or distributed to any other person. It is >>provided without any warranty whatsoever and unless stated otherwise >>consists purely of indicative market prices and other information. >> >>Any opinion or comments expressed or assumption made in association >>with the data or information provided in this email is a reflection of >>CreditTrades judgement at the time of compiling the data and is >>subject to change. CreditTrade hereby makes no representation and >>accepts no responsibility or liability as to the completeness or >>accuracy of this email. >> >>The content of this email is not intended as an offer or solicitation >>for, or recommendation of, the purchase or sale of any financial >>instrument, or as an official confirmation of any transaction, and >>should not be construed as investment advice. >> >>- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >>CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All >>rights reserved. The information and data contained in this email is >>provided for the information purposes of the addressee only and should >>not be reproduced and/or distributed to any other person. It is >>provided without any warranty whatsoever and unless stated otherwise >>consists purely of indicative market prices and other information. >> >>Any opinion or comments expressed or assumption made in association >>with the data or information provided in this email is a reflection of >>CreditTrades judgement at the time of compiling the data and is >>subject to change. CreditTrade hereby makes no representation and >>accepts no responsibility or liability as to the completeness or >>accuracy of this email. >> >>The content of this email is not intended as an offer or solicitat
Re: Auto incremented primary key and extents
Hi Mark, Mark Rowell wrote: Sorry After looking at SequenceManaherHelper I know that the max id of sequence for extent is not... More on the batch mode stuff -- I onlt just turned it on and got these problems. RC4 has been working Prior to setting batch-mode="true" in the configuration. hmm, AFAIK Oleg has fixed some bugs in conjunction with batch mode (since rc4). So your problems maybe a side-effect of the bugs in batch-mode. regards, Armin -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:25 To: 'OJB Users List' Subject: RE: Auto incremented primary key and extents Armin No the only thing I changed was OJB.properties. One thing is that this problem happened during a run of my application where some batch mode=true stuff Was used. Would this have an impact? Is the sequence max id still stored in OJB_HL_SEQ? Regards Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:21 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, > But as a follow on the extents are more than one level deep -- would > this > have an impact? No should not. Have a look in SequenceManagerHelper#getMaxForExtent > unique Over all tables in the extent? Have I misconfigured OJB on upgrading > to RC4? Did you change metadata on upgrading? Add new extents, change order of declaration? regards, Armin Mark Rowell wrote: Sorry But as a follow on the extents are more than one level deep -- would this have an impact? Regards, Mark Rowell -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 11:30 To: '[EMAIL PROTECTED]' Subject: Auto incremented primary key and extents Hi I have an extent over 8 classes (and 8 corresponding tables) and I have noticed that primary keys are now not unique over all tables -- e.g. when I store and instances of 2 different classes In different "leaves" of the extent I get the same ID in both tables. In RC1 I the autogenerated IDs were unique Over all tables in the extent? Have I misconfigured OJB on upgrading to RC4? Regards, Mark Rowell --- Mark Rowell Structured Credit Europe CreditTrade Limited 180 Fleet Street London EC4A 2HG Tel +44 (0)20 7400 5078 Fax +44 (0)20 7400 5099 http://www.credittrade.com CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All rights reserved. The information and data contained in this email is provided for the information purposes of the addressee only and should not be reproduced and/or distributed to any other person. It is provided without any warranty whatsoever and unless stated otherwise consists purely of indicative market prices and other information. Any opinion or comments expressed or assumption made in association with the data or information provided in this email is a reflection of CreditTrades judgement at the time of compiling the data and is subject to change. CreditTrade hereby makes no representation and accepts no responsibility or liability as to the completeness or accuracy of this email. The content of this email is not intended as an offer or solicitation for, or recommendation of, the purchase or sale of any financial instrument, or as an official confirmation of any transaction, and should not be construed as investment advice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All rights reserved. The information and data contained in this email is provided for the information purposes of the addressee only and should not be reproduced and/or distributed to any other person. It is provided without any warranty whatsoever and unless stated otherwise consists purely of indicative market prices and other information. Any opinion or comments expressed or assumption made in association with the data or information provided in this email is a reflection of CreditTrades judgement at the time of compiling the data and is subject to change. CreditTrade hereby makes no representation and accepts no responsibility or liability as to the completeness or accuracy of this email. The content of this email is not intended as an offer or solicitation for, or recommendation of, the purchase or sale of any financial instrument, or as an official confirmation of any transaction, and should not be construed as investment advice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All ri
NPE in TableAlias.hashCode, was: RE: java.lang.StackOverflowErro r
Hello, > -Original Message- > From: Christophe.Demarey [mailto:[EMAIL PROTECTED] > I correct my repository definition (remove the table attribut from > PersonBaseImpl descriptor) but I still get an exception. > Any idea about it ? > > java.lang.NullPointerException > at > org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableA > lias.hashCode(Unknown > Source) > at java.util.HashMap.hash(HashMap.java:250) > at java.util.HashMap.put(HashMap.java:363) I had that exception, too. If I recall it correctly, it occurs whenever a non-abstract class does not have a table-attribute. Besides, in occurs when the first class of an extent is not a concrete class, and that extent is referenced by a collection- or reference-descriptor. You may try to add some table attributes or post the repository_user.xml and let us have a look at it. Olli - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Auto incremented primary key and extents
Sorry After looking at SequenceManaherHelper I know that the max id of sequence for extent is not... More on the batch mode stuff -- I onlt just turned it on and got these problems. RC4 has been working Prior to setting batch-mode="true" in the configuration. -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:25 To: 'OJB Users List' Subject: RE: Auto incremented primary key and extents Armin No the only thing I changed was OJB.properties. One thing is that this problem happened during a run of my application where some batch mode=true stuff Was used. Would this have an impact? Is the sequence max id still stored in OJB_HL_SEQ? Regards Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:21 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, > But as a follow on the extents are more than one level deep -- would > this > have an impact? No should not. Have a look in SequenceManagerHelper#getMaxForExtent > unique Over all tables in the extent? Have I misconfigured OJB on upgrading > to RC4? Did you change metadata on upgrading? Add new extents, change order of declaration? regards, Armin Mark Rowell wrote: > Sorry > > But as a follow on the extents are more than one level deep -- would > this have an impact? > > Regards, > > Mark Rowell > > -Original Message- > From: Mark Rowell [mailto:[EMAIL PROTECTED] > Sent: 27 October 2003 11:30 > To: '[EMAIL PROTECTED]' > Subject: Auto incremented primary key and extents > > > Hi > > I have an extent over 8 classes (and 8 corresponding tables) and I > have noticed that primary keys are now not unique over all tables -- > e.g. when I store and instances of 2 different classes In different > "leaves" of the extent I get the same ID in both tables. In RC1 I the > autogenerated IDs were unique Over all tables in the extent? Have I > misconfigured OJB on upgrading to RC4? > > Regards, > > Mark Rowell > > --- > Mark Rowell > Structured Credit Europe > CreditTrade Limited > 180 Fleet Street > London EC4A 2HG > > Tel +44 (0)20 7400 5078 > Fax +44 (0)20 7400 5099 > > http://www.credittrade.com > > > > CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All > rights reserved. The information and data contained in this email is > provided for the information purposes of the addressee only and should > not be reproduced and/or distributed to any other person. It is > provided without any warranty whatsoever and unless stated otherwise > consists purely of indicative market prices and other information. > > Any opinion or comments expressed or assumption made in association > with the data or information provided in this email is a reflection of > CreditTrades judgement at the time of compiling the data and is > subject to change. CreditTrade hereby makes no representation and > accepts no responsibility or liability as to the completeness or > accuracy of this email. > > The content of this email is not intended as an offer or solicitation > for, or recommendation of, the purchase or sale of any financial > instrument, or as an official confirmation of any transaction, and > should not be construed as investment advice. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All > rights reserved. The information and data contained in this email is > provided for the information purposes of the addressee only and should > not be reproduced and/or distributed to any other person. It is > provided without any warranty whatsoever and unless stated otherwise > consists purely of indicative market prices and other information. > > Any opinion or comments expressed or assumption made in association > with the data or information provided in this email is a reflection of > CreditTrades judgement at the time of compiling the data and is > subject to change. CreditTrade hereby makes no representation and > accepts no responsibility or liability as to the completeness or > accuracy of this email. > > The content of this email is not intended as an offer or solicitation > for, or recommendation of, the purchase or sale of any financial > instrument, or as an official confirmation of any transaction, and > should not be construed as investment advice. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) CreditTrade 20
RE: Auto incremented primary key and extents
Armin No the only thing I changed was OJB.properties. One thing is that this problem happened during a run of my application where some batch mode=true stuff Was used. Would this have an impact? Is the sequence max id still stored in OJB_HL_SEQ? Regards Mark -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 12:21 To: OJB Users List Subject: Re: Auto incremented primary key and extents Hi Mark, > But as a follow on the extents are more than one level deep -- would > this > have an impact? No should not. Have a look in SequenceManagerHelper#getMaxForExtent > unique Over all tables in the extent? Have I misconfigured OJB on upgrading > to RC4? Did you change metadata on upgrading? Add new extents, change order of declaration? regards, Armin Mark Rowell wrote: > Sorry > > But as a follow on the extents are more than one level deep -- would > this have an impact? > > Regards, > > Mark Rowell > > -Original Message- > From: Mark Rowell [mailto:[EMAIL PROTECTED] > Sent: 27 October 2003 11:30 > To: '[EMAIL PROTECTED]' > Subject: Auto incremented primary key and extents > > > Hi > > I have an extent over 8 classes (and 8 corresponding tables) and I > have noticed that primary keys are now not unique over all tables -- > e.g. when I store and instances of 2 different classes In different > "leaves" of the extent I get the same ID in both tables. In RC1 I the > autogenerated IDs were unique Over all tables in the extent? Have I > misconfigured OJB on upgrading to RC4? > > Regards, > > Mark Rowell > > --- > Mark Rowell > Structured Credit Europe > CreditTrade Limited > 180 Fleet Street > London EC4A 2HG > > Tel +44 (0)20 7400 5078 > Fax +44 (0)20 7400 5099 > > http://www.credittrade.com > > > > CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All > rights reserved. The information and data contained in this email is > provided for the information purposes of the addressee only and should > not be reproduced and/or distributed to any other person. It is > provided without any warranty whatsoever and unless stated otherwise > consists purely of indicative market prices and other information. > > Any opinion or comments expressed or assumption made in association > with the data or information provided in this email is a reflection of > CreditTrades judgement at the time of compiling the data and is > subject to change. CreditTrade hereby makes no representation and > accepts no responsibility or liability as to the completeness or > accuracy of this email. > > The content of this email is not intended as an offer or solicitation > for, or recommendation of, the purchase or sale of any financial > instrument, or as an official confirmation of any transaction, and > should not be construed as investment advice. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All > rights reserved. The information and data contained in this email is > provided for the information purposes of the addressee only and should > not be reproduced and/or distributed to any other person. It is > provided without any warranty whatsoever and unless stated otherwise > consists purely of indicative market prices and other information. > > Any opinion or comments expressed or assumption made in association > with the data or information provided in this email is a reflection of > CreditTrades judgement at the time of compiling the data and is > subject to change. CreditTrade hereby makes no representation and > accepts no responsibility or liability as to the completeness or > accuracy of this email. > > The content of this email is not intended as an offer or solicitation > for, or recommendation of, the purchase or sale of any financial > instrument, or as an official confirmation of any transaction, and > should not be construed as investment advice. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All rights reserved. The information and data contained in this email is provided 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 d
Re: Auto incremented primary key and extents
Hi Mark, > But as a follow on the extents are more than one level deep -- would > this > have an impact? No should not. Have a look in SequenceManagerHelper#getMaxForExtent > unique Over all tables in the extent? Have I misconfigured OJB on upgrading > to RC4? Did you change metadata on upgrading? Add new extents, change order of declaration? regards, Armin Mark Rowell wrote: Sorry But as a follow on the extents are more than one level deep -- would this have an impact? Regards, Mark Rowell -Original Message- From: Mark Rowell [mailto:[EMAIL PROTECTED] Sent: 27 October 2003 11:30 To: '[EMAIL PROTECTED]' Subject: Auto incremented primary key and extents Hi I have an extent over 8 classes (and 8 corresponding tables) and I have noticed that primary keys are now not unique over all tables -- e.g. when I store and instances of 2 different classes In different "leaves" of the extent I get the same ID in both tables. In RC1 I the autogenerated IDs were unique Over all tables in the extent? Have I misconfigured OJB on upgrading to RC4? Regards, Mark Rowell --- Mark Rowell Structured Credit Europe CreditTrade Limited 180 Fleet Street London EC4A 2HG Tel +44 (0)20 7400 5078 Fax +44 (0)20 7400 5099 http://www.credittrade.com CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All rights reserved. The information and data contained in this email is provided for the information purposes of the addressee only and should not be reproduced and/or distributed to any other person. It is provided without any warranty whatsoever and unless stated otherwise consists purely of indicative market prices and other information. Any opinion or comments expressed or assumption made in association with the data or information provided in this email is a reflection of CreditTrades judgement at the time of compiling the data and is subject to change. CreditTrade hereby makes no representation and accepts no responsibility or liability as to the completeness or accuracy of this email. The content of this email is not intended as an offer or solicitation for, or recommendation of, the purchase or sale of any financial instrument, or as an official confirmation of any transaction, and should not be construed as investment advice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All rights reserved. The information and data contained in this email is provided for the information purposes of the addressee only and should not be reproduced and/or distributed to any other person. It is provided without any warranty whatsoever and unless stated otherwise consists purely of indicative market prices and other information. Any opinion or comments expressed or assumption made in association with the data or information provided in this email is a reflection of CreditTrades judgement at the time of compiling the data and is subject to change. CreditTrade hereby makes no representation and accepts no responsibility or liability as to the completeness or accuracy of this email. The content of this email is not intended as an offer or solicitation for, or recommendation of, the purchase or sale of any financial instrument, or as an official confirmation of any transaction, and should not be construed as investment advice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problem with PB instances creation
Hi,
Charles Anthony wrote:
Hi,
Hello,
OK! It is a bit clearer for me, thanks.
Each time I want to use a broker I should do:
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
//I use the broker
broker.close();
Yes, this is the way it should be done.
Is it better to do this EACH time I use the broker or ask for
a broker one time (when the application start) and close
after (all) the use?
It is better to do it each time.
If this is an "issue" for you, I suggest you look at using ODMG; it hides
all broker usage from your application.
About the MAX number of broker in OJB.properties, is it a
good way to set this number to 100 or even 1000?
Finally what is the exact meaning of this 2 log messages:
"Already created persistence broker instances: x"?
"Already created connections: 3 returning: ..."?
I'm afraid I don't know precisely..
Never mind! ;-)
PersistenceBroker instances and connections are
"decoupled" and OJB use a pool for PB instances
and does (by default) pool the connections.
>> "Already created persistence broker instances: x"?
Number of created PB instances
>> "Already created connections: 3 returning: ..."?
Number of overall created connections
regards,
Armin
Cheers,
Charles.
Thanks for your help
Sylvain
-Message d'origine-
De: Charles Anthony [mailto:[EMAIL PROTECTED]
Date: lundi, 27. octobre 2003 11:27
À: 'OJB Users List'
Objet: RE: problem with PB instances creation
Hi,
at line 27, you should repeat lines 9-13.
At line 10
PersistenceBrokerFactory.defaultPersistenceBroker() asks the pool
for a broker, creating one *if* *necessary*.
broker.close releases some resources from the broker, and returns the
broker to the pool.
In other words, after you close the broker, you can no longer
use it. You
must get another broker.
If you really need to know how many (active) brokers there
are in the pool,
you should be able to do
PersistenceBrokerFactoryDefaultImpl factory =
(PersistenceBrokerFactoryDefaultImpl)
PersistenceBrokerFactoryFactory.instance();
int brokersInPool = factory.activePersistenceBroker();
Cheers,
Charles
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: 27 October 2003 10:17
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: problem with PB instances creation
Hello Thomas,
Is there a way to check how many instances are contained in
the pool?
You can find an example below.
You create a broker instance in line 10, right?
You use the broker instance first time in line 19. After this
use you close() the instance.
But the problem is if you do the close() in line 25 when you
use the broker for the second time in line 29 you have a
ConnectionNotInProgressException.
Do I have to create a second broker?
Or do I have to call a broker from the pool? How?
Thanks for your help
Sylvain
1 public class MyExample {
2
3 private PersistenceBroker broker;
4
5 public void test() {
6 /**
7 * Persistence Broker
8 */
9 try {
10 broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
11 } catch (Throwable t) {
12 t.printStackTrace();
13 }
14
15 Criteria crit = new Criteria();
16 ...
17
18 try {
19 broker.beginTransaction();
20 //query 1...
21 broker.commitTransaction();
22 } catch (Throwable t) {
23 broker.abortTransaction();
24 } finally {
25 broker.close();
26 }
27
28 try {
29 broker.beginTransaction();
30 //query 2...
31 broker.commitTransaction();
32 } catch (Throwable t) {
33 broker.abortTransaction();
34 } finally {
35 broker.close();
36 }
37 }
38 }
-Message d'origine-
De: Thomas Mahler [mailto:[EMAIL PROTECTED]
Date: vendredi, 24. octobre 2003 18:17
À: OJB Users List
Objet: Re: problem with PB instances creation
Hi Sylvain,
[EMAIL PROTECTED] wrote:
Hello,
I'm using OJB in my web application and I have some problem
with PB instances creation.
Each time I want to read/write data from/to my database I
create a PB intance:
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
The problem is that lot of PB instances are created and
never destroyed.
I can see that in logs: "Already created persistence broker
instances: x".
For that I close the broker instance each time:
broker.close();
But I have noticed that this function doesn't destroy the
PB instance.
So what is the job of this function?
broker instances are not destroyed, because it's expensive
to create
them. Thus OJB is pooling broker instances.
broker.close() simply makes the instances unavailable for
further calls
and puts the instance back to the pool.
How to destroy PB instance and prevent that the number of
PB instances is equal to the maximum?
If you close broker instancecs always after usage the number
of active
broker instances (i.e. brokers that are borrowed from the
pool) equals
the number servlet instances requesting a broker.
You can change the broker pool behaviour through settings in
OJB.properties:
# specifies the behaviour of the pool when broker capacity is
# ex
RE: problem with PB instances creation
Hi,
>
> Hello,
>
> OK! It is a bit clearer for me, thanks.
> Each time I want to use a broker I should do:
>
> broker = PersistenceBrokerFactory.defaultPersistenceBroker();
> //I use the broker
> broker.close();
Yes, this is the way it should be done.
> Is it better to do this EACH time I use the broker or ask for
> a broker one time (when the application start) and close
> after (all) the use?
It is better to do it each time.
If this is an "issue" for you, I suggest you look at using ODMG; it hides
all broker usage from your application.
> About the MAX number of broker in OJB.properties, is it a
> good way to set this number to 100 or even 1000?
>
> Finally what is the exact meaning of this 2 log messages:
> "Already created persistence broker instances: x"?
> "Already created connections: 3 returning: ..."?
I'm afraid I don't know precisely..
Cheers,
Charles.
> Thanks for your help
> Sylvain
>
>
>
>
> -Message d'origine-
> De: Charles Anthony [mailto:[EMAIL PROTECTED]
> Date: lundi, 27. octobre 2003 11:27
> À: 'OJB Users List'
> Objet: RE: problem with PB instances creation
>
>
> Hi,
>
> at line 27, you should repeat lines 9-13.
>
> At line 10
> PersistenceBrokerFactory.defaultPersistenceBroker() asks the pool
> for a broker, creating one *if* *necessary*.
> broker.close releases some resources from the broker, and returns the
> broker to the pool.
>
> In other words, after you close the broker, you can no longer
> use it. You
> must get another broker.
>
> If you really need to know how many (active) brokers there
> are in the pool,
> you should be able to do
>
> PersistenceBrokerFactoryDefaultImpl factory =
> (PersistenceBrokerFactoryDefaultImpl)
> PersistenceBrokerFactoryFactory.instance();
> int brokersInPool = factory.activePersistenceBroker();
>
> Cheers,
>
> Charles
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> > Sent: 27 October 2003 10:17
> > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Subject: RE: problem with PB instances creation
> >
> >
> > Hello Thomas,
> >
> > Is there a way to check how many instances are contained in
> the pool?
> >
> > You can find an example below.
> > You create a broker instance in line 10, right?
> > You use the broker instance first time in line 19. After this
> > use you close() the instance.
> > But the problem is if you do the close() in line 25 when you
> > use the broker for the second time in line 29 you have a
> > ConnectionNotInProgressException.
> >
> > Do I have to create a second broker?
> > Or do I have to call a broker from the pool? How?
> >
> > Thanks for your help
> > Sylvain
> >
> >
> > 1 public class MyExample {
> > 2
> > 3 private PersistenceBroker broker;
> > 4
> > 5 public void test() {
> > 6 /**
> > 7 * Persistence Broker
> > 8 */
> > 9 try {
> > 10 broker =
> > PersistenceBrokerFactory.defaultPersistenceBroker();
> > 11 } catch (Throwable t) {
> > 12 t.printStackTrace();
> > 13 }
> > 14
> > 15 Criteria crit = new Criteria();
> > 16 ...
> > 17
> > 18 try {
> > 19 broker.beginTransaction();
> > 20 //query 1...
> > 21 broker.commitTransaction();
> > 22 } catch (Throwable t) {
> > 23 broker.abortTransaction();
> > 24 } finally {
> > 25 broker.close();
> > 26 }
> > 27
> > 28 try {
> > 29 broker.beginTransaction();
> > 30 //query 2...
> > 31 broker.commitTransaction();
> > 32 } catch (Throwable t) {
> > 33 broker.abortTransaction();
> > 34 } finally {
> > 35 broker.close();
> > 36 }
> > 37 }
> > 38 }
> >
> >
> > -Message d'origine-
> > De: Thomas Mahler [mailto:[EMAIL PROTECTED]
> > Date: vendredi, 24. octobre 2003 18:17
> > À: OJB Users List
> > Objet: Re: problem with PB instances creation
> >
> >
> > Hi Sylvain,
> >
> > [EMAIL PROTECTED] wrote:
> > > Hello,
> > >
> > > I'm using OJB in my web application and I have some problem
> > with PB instances creation.
> > >
> > > Each time I want to read/write data from/to my database I
> > create a PB intance:
> > > broker = PersistenceBrokerFactory.defaultPersistenceBroker();
> > >
> > > The problem is that lot of PB instances are created and
> > never destroyed.
> > > I can see that in logs: "Already created persistence broker
> > instances: x".
> > > For that I close the broker instance each time:
> > > broker.close();
> > >
> > > But I have noticed that this function doesn't destroy the
> > PB instance.
> > > So what is the job of this function?
> >
> > broker instances are not destroyed, because it's expensive
> to create
> > them. Thus OJB is pooling broker instances.
> > broker.close() simply makes the instances unavailable for
> > further calls
> > and puts the instance back to the pool.
> >
> > > How to destroy PB instance and prevent that the number of
> > PB instances is equal to the maximum?
> >
> > If you close broke
RE: problem with PB instances creation
Hello,
OK! It is a bit clearer for me, thanks.
Each time I want to use a broker I should do:
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
//I use the broker
broker.close();
Is it better to do this EACH time I use the broker or ask for a broker one time (when
the application start) and close after (all) the use?
About the MAX number of broker in OJB.properties, is it a good way to set this number
to 100 or even 1000?
Finally what is the exact meaning of this 2 log messages:
"Already created persistence broker instances: x"?
"Already created connections: 3 returning: ..."?
Thanks for your help
Sylvain
-Message d'origine-
De: Charles Anthony [mailto:[EMAIL PROTECTED]
Date: lundi, 27. octobre 2003 11:27
À: 'OJB Users List'
Objet: RE: problem with PB instances creation
Hi,
at line 27, you should repeat lines 9-13.
At line 10 PersistenceBrokerFactory.defaultPersistenceBroker() asks the pool
for a broker, creating one *if* *necessary*.
broker.close releases some resources from the broker, and returns the
broker to the pool.
In other words, after you close the broker, you can no longer use it. You
must get another broker.
If you really need to know how many (active) brokers there are in the pool,
you should be able to do
PersistenceBrokerFactoryDefaultImpl factory =
(PersistenceBrokerFactoryDefaultImpl)
PersistenceBrokerFactoryFactory.instance();
int brokersInPool = factory.activePersistenceBroker();
Cheers,
Charles
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 27 October 2003 10:17
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: problem with PB instances creation
>
>
> Hello Thomas,
>
> Is there a way to check how many instances are contained in the pool?
>
> You can find an example below.
> You create a broker instance in line 10, right?
> You use the broker instance first time in line 19. After this
> use you close() the instance.
> But the problem is if you do the close() in line 25 when you
> use the broker for the second time in line 29 you have a
> ConnectionNotInProgressException.
>
> Do I have to create a second broker?
> Or do I have to call a broker from the pool? How?
>
> Thanks for your help
> Sylvain
>
>
> 1 public class MyExample {
> 2
> 3 private PersistenceBroker broker;
> 4
> 5 public void test() {
> 6 /**
> 7 * Persistence Broker
> 8 */
> 9 try {
> 10broker =
> PersistenceBrokerFactory.defaultPersistenceBroker();
> 11} catch (Throwable t) {
> 12t.printStackTrace();
> 13}
> 14
> 15Criteria crit = new Criteria();
> 16...
> 17
> 18try {
> 19broker.beginTransaction();
> 20//query 1...
> 21broker.commitTransaction();
> 22} catch (Throwable t) {
> 23broker.abortTransaction();
> 24} finally {
> 25broker.close();
> 26}
> 27
> 28try {
> 29broker.beginTransaction();
> 30//query 2...
> 31broker.commitTransaction();
> 32} catch (Throwable t) {
> 33broker.abortTransaction();
> 34} finally {
> 35broker.close();
> 36}
> 37 }
> 38 }
>
>
> -Message d'origine-
> De: Thomas Mahler [mailto:[EMAIL PROTECTED]
> Date: vendredi, 24. octobre 2003 18:17
> À: OJB Users List
> Objet: Re: problem with PB instances creation
>
>
> Hi Sylvain,
>
> [EMAIL PROTECTED] wrote:
> > Hello,
> >
> > I'm using OJB in my web application and I have some problem
> with PB instances creation.
> >
> > Each time I want to read/write data from/to my database I
> create a PB intance:
> > broker = PersistenceBrokerFactory.defaultPersistenceBroker();
> >
> > The problem is that lot of PB instances are created and
> never destroyed.
> > I can see that in logs: "Already created persistence broker
> instances: x".
> > For that I close the broker instance each time:
> > broker.close();
> >
> > But I have noticed that this function doesn't destroy the
> PB instance.
> > So what is the job of this function?
>
> broker instances are not destroyed, because it's expensive to create
> them. Thus OJB is pooling broker instances.
> broker.close() simply makes the instances unavailable for
> further calls
> and puts the instance back to the pool.
>
> > How to destroy PB instance and prevent that the number of
> PB instances is equal to the maximum?
>
> If you close broker instancecs always after usage the number
> of active
> broker instances (i.e. brokers that are borrowed from the
> pool) equals
> the number servlet instances requesting a broker.
>
> You can change the broker pool behaviour through settings in
> OJB.properties:
>
> # specifies the behaviour of the pool when broker capacity is
> # exhausted (see maxActive above)
> # 0 - fail
> # 1 - block
> # 2 - grow
> whenExhaustedAction=0
>
> The default setting is 0, so the pool throws an exception if
> an instance
> is requested when the
RE: Auto incremented primary key and extents
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]
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]
RE: problem with PB instances creation
Hi,
at line 27, you should repeat lines 9-13.
At line 10 PersistenceBrokerFactory.defaultPersistenceBroker() asks the pool
for a broker, creating one *if* *necessary*.
broker.close releases some resources from the broker, and returns the
broker to the pool.
In other words, after you close the broker, you can no longer use it. You
must get another broker.
If you really need to know how many (active) brokers there are in the pool,
you should be able to do
PersistenceBrokerFactoryDefaultImpl factory =
(PersistenceBrokerFactoryDefaultImpl)
PersistenceBrokerFactoryFactory.instance();
int brokersInPool = factory.activePersistenceBroker();
Cheers,
Charles
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 27 October 2003 10:17
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: problem with PB instances creation
>
>
> Hello Thomas,
>
> Is there a way to check how many instances are contained in the pool?
>
> You can find an example below.
> You create a broker instance in line 10, right?
> You use the broker instance first time in line 19. After this
> use you close() the instance.
> But the problem is if you do the close() in line 25 when you
> use the broker for the second time in line 29 you have a
> ConnectionNotInProgressException.
>
> Do I have to create a second broker?
> Or do I have to call a broker from the pool? How?
>
> Thanks for your help
> Sylvain
>
>
> 1 public class MyExample {
> 2
> 3 private PersistenceBroker broker;
> 4
> 5 public void test() {
> 6 /**
> 7 * Persistence Broker
> 8 */
> 9 try {
> 10broker =
> PersistenceBrokerFactory.defaultPersistenceBroker();
> 11} catch (Throwable t) {
> 12t.printStackTrace();
> 13}
> 14
> 15Criteria crit = new Criteria();
> 16...
> 17
> 18try {
> 19broker.beginTransaction();
> 20//query 1...
> 21broker.commitTransaction();
> 22} catch (Throwable t) {
> 23broker.abortTransaction();
> 24} finally {
> 25broker.close();
> 26}
> 27
> 28try {
> 29broker.beginTransaction();
> 30//query 2...
> 31broker.commitTransaction();
> 32} catch (Throwable t) {
> 33broker.abortTransaction();
> 34} finally {
> 35broker.close();
> 36}
> 37 }
> 38 }
>
>
> -Message d'origine-
> De: Thomas Mahler [mailto:[EMAIL PROTECTED]
> Date: vendredi, 24. octobre 2003 18:17
> À: OJB Users List
> Objet: Re: problem with PB instances creation
>
>
> Hi Sylvain,
>
> [EMAIL PROTECTED] wrote:
> > Hello,
> >
> > I'm using OJB in my web application and I have some problem
> with PB instances creation.
> >
> > Each time I want to read/write data from/to my database I
> create a PB intance:
> > broker = PersistenceBrokerFactory.defaultPersistenceBroker();
> >
> > The problem is that lot of PB instances are created and
> never destroyed.
> > I can see that in logs: "Already created persistence broker
> instances: x".
> > For that I close the broker instance each time:
> > broker.close();
> >
> > But I have noticed that this function doesn't destroy the
> PB instance.
> > So what is the job of this function?
>
> broker instances are not destroyed, because it's expensive to create
> them. Thus OJB is pooling broker instances.
> broker.close() simply makes the instances unavailable for
> further calls
> and puts the instance back to the pool.
>
> > How to destroy PB instance and prevent that the number of
> PB instances is equal to the maximum?
>
> If you close broker instancecs always after usage the number
> of active
> broker instances (i.e. brokers that are borrowed from the
> pool) equals
> the number servlet instances requesting a broker.
>
> You can change the broker pool behaviour through settings in
> OJB.properties:
>
> # specifies the behaviour of the pool when broker capacity is
> # exhausted (see maxActive above)
> # 0 - fail
> # 1 - block
> # 2 - grow
> whenExhaustedAction=0
>
> The default setting is 0, so the pool throws an exception if
> an instance
> is requested when the pool is exhausted.
> By setting this value to 2 the pool would simply grow and a
> new broker
> instance.
> By setting it to 1 you can avoid growing of the pool, the
> application is
> blockes until an instance is available from the pool.
>
> cheers,
> Thomas
>
>
> > Thanks for any help
> > Sylvain
> >
> >
> >
>
>
> -
> 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 rec
RE: problem with PB instances creation
Hello Thomas,
Is there a way to check how many instances are contained in the pool?
You can find an example below.
You create a broker instance in line 10, right?
You use the broker instance first time in line 19. After this use you close() the
instance.
But the problem is if you do the close() in line 25 when you use the broker for the
second time in line 29 you have a ConnectionNotInProgressException.
Do I have to create a second broker?
Or do I have to call a broker from the pool? How?
Thanks for your help
Sylvain
1 public class MyExample {
2
3 private PersistenceBroker broker;
4
5 public void test() {
6 /**
7 * Persistence Broker
8 */
9 try {
10 broker = PersistenceBrokerFactory.defaultPersistenceBroker();
11 } catch (Throwable t) {
12 t.printStackTrace();
13 }
14
15 Criteria crit = new Criteria();
16 ...
17
18 try {
19 broker.beginTransaction();
20 //query 1...
21 broker.commitTransaction();
22 } catch (Throwable t) {
23 broker.abortTransaction();
24 } finally {
25 broker.close();
26 }
27
28 try {
29 broker.beginTransaction();
30 //query 2...
31 broker.commitTransaction();
32 } catch (Throwable t) {
33 broker.abortTransaction();
34 } finally {
35 broker.close();
36 }
37 }
38 }
-Message d'origine-
De: Thomas Mahler [mailto:[EMAIL PROTECTED]
Date: vendredi, 24. octobre 2003 18:17
À: OJB Users List
Objet: Re: problem with PB instances creation
Hi Sylvain,
[EMAIL PROTECTED] wrote:
> Hello,
>
> I'm using OJB in my web application and I have some problem with PB instances
> creation.
>
> Each time I want to read/write data from/to my database I create a PB intance:
> broker = PersistenceBrokerFactory.defaultPersistenceBroker();
>
> The problem is that lot of PB instances are created and never destroyed.
> I can see that in logs: "Already created persistence broker instances: x".
> For that I close the broker instance each time:
> broker.close();
>
> But I have noticed that this function doesn't destroy the PB instance.
> So what is the job of this function?
broker instances are not destroyed, because it's expensive to create
them. Thus OJB is pooling broker instances.
broker.close() simply makes the instances unavailable for further calls
and puts the instance back to the pool.
> How to destroy PB instance and prevent that the number of PB instances is equal to
> the maximum?
If you close broker instancecs always after usage the number of active
broker instances (i.e. brokers that are borrowed from the pool) equals
the number servlet instances requesting a broker.
You can change the broker pool behaviour through settings in OJB.properties:
# specifies the behaviour of the pool when broker capacity is
# exhausted (see maxActive above)
# 0 - fail
# 1 - block
# 2 - grow
whenExhaustedAction=0
The default setting is 0, so the pool throws an exception if an instance
is requested when the pool is exhausted.
By setting this value to 2 the pool would simply grow and a new broker
instance.
By setting it to 1 you can avoid growing of the pool, the application is
blockes until an instance is available from the pool.
cheers,
Thomas
> Thanks for any help
> Sylvain
>
>
>
-
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]
Question to developers: EnhancedOQLQuery and Query
Is it possible to combine functionality of EnhancedOQLQuery and Query? I want to choose whether I need to get collection or iterator as a result of OQL query. I want to use OQL as a basis to look up my objects, but some time I need iterator. And I don't want to mix use of EnhancedOQLQuery and Query in my code. If I'm right, the implementation of EnhancedOQLQuery is based on Query. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE : Lock position ??
Thanks a lot Gerhard !
We all use ODMG, do we all have used lock(Write) and not
Database.makePersistent().
But if you tell me that we have to lock for an update bedfore any
modification it is clearer for me and explain why we have this behavious.
Thank you very much !!
-Message d'origine-
De : news [mailto:[EMAIL PROTECTED] De la part de Gerhard Grosse
Envoyé : lundi 27 octobre 2003 09:19
À : [EMAIL PROTECTED]
Objet : Re: Lock position ??
Hi Emmanuel,
AFAIK it shouldn't matter when you acquire a lock for new objects.
(Although it might affect the order of SQL statements during commit).
Btw, for new objects you can also use Database.makePersistent(), which
imo makes the intention of inserting a new object clearer.
For objects to update, you definetely should acquire a write lock
before doing any object modifications, because during commit OJB will
compare the state of your object against the state when you acquired
the lock to find out whether the object needs to be updated or not.
HTH,
Gerhard
On Fri, 24 Oct 2003 18:02:21 +0200, "Emmanuel Dupont"
<[EMAIL PROTECTED]> wrote:
>All,
>
>
>
>
>
>I'm driving nuts. Is there definitely a position for the lock on ODMG ?
>
>
>
>I explain, sometimes our updates are done if the lock on an object is done
>before its affectations and sometimes it has to de done after.
>
>
>
>I 'm really confused. I don't explain that. Our developers don't also.
>
>
>
>Ex :
>
>
>
>JdoClient client = new JdoClient();
>
>
>
>Client.setId(10);
>
>client.setName("Toto");
>
>client.setproduct_FK(12);
>
>
>
>Tx.lock(client, Write); <===
>
>
>
>And sometimes we have to do that :
>
>
>
>JdoClient client = new JdoClient();
>
>
>
>Client.setId(10);
>
>
>
>Tx.lock(client, Write); <===
>
>
>
>client.setName("Toto");
>
>client.setproduct_FK(12);
>
>
>
>It seems that it is different between an update and a creation.
>
>
>
>A lock should be before for the update and after for the creation.
>
>
>
>This is completely weird isn't it ??
>
>
>
>
>
>Tell me if it is completely stupid...
>
>
>
>
>
>
>
>
-
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: someone please tell me...
Andy I found this as well but I have taken the extra step of prechecking which of my objects exist so rather Than doing a broker.store(object) I can call the store method that tells OJB to update or insert -- stops OJB querying to see if object exists. Must admit it does seem strange though... Mark -Original Message- From: Andy Czerwonka [mailto:[EMAIL PROTECTED] Sent: 25 October 2003 00:53 To: OJB Users List Subject: someone please tell me... How could batch-mode=true be slower than batch-mode=false??? OJB rc4 + small batch-mode hack (Mark Rowell) Oracle9i ojdbc14.jar - 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: Lock position ??
Hi Emmanuel,
AFAIK it shouldn't matter when you acquire a lock for new objects.
(Although it might affect the order of SQL statements during commit).
Btw, for new objects you can also use Database.makePersistent(), which
imo makes the intention of inserting a new object clearer.
For objects to update, you definetely should acquire a write lock
before doing any object modifications, because during commit OJB will
compare the state of your object against the state when you acquired
the lock to find out whether the object needs to be updated or not.
HTH,
Gerhard
On Fri, 24 Oct 2003 18:02:21 +0200, "Emmanuel Dupont"
<[EMAIL PROTECTED]> wrote:
>All,
>
>
>
>
>
>I'm driving nuts. Is there definitely a position for the lock on ODMG ?
>
>
>
>I explain, sometimes our updates are done if the lock on an object is done
>before its affectations and sometimes it has to de done after.
>
>
>
>I 'm really confused. I don't explain that. Our developers don't also.
>
>
>
>Ex :
>
>
>
>JdoClient client = new JdoClient();
>
>
>
>Client.setId(10);
>
>client.setName("Toto");
>
>client.setproduct_FK(12);
>
>
>
>Tx.lock(client, Write); <===
>
>
>
>And sometimes we have to do that :
>
>
>
>JdoClient client = new JdoClient();
>
>
>
>Client.setId(10);
>
>
>
>Tx.lock(client, Write); <===
>
>
>
>client.setName("Toto");
>
>client.setproduct_FK(12);
>
>
>
>It seems that it is different between an update and a creation.
>
>
>
>A lock should be before for the update and after for the creation.
>
>
>
>This is completely weird isn't it ??
>
>
>
>
>
>Tell me if it is completely stupid...
>
>
>
>
>
>
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new feature] Proxy prefetching
On Monday 27 October 2003 00:25, Antonio Gallardo wrote: > Oleg Nitz dijo: > > On Sunday 26 October 2003 23:12, Antonio Gallardo wrote: > >> Can this work with JDO? > > > > Yes, this is done at the PB level, therefore works for ODMG, OTM and > > JDO. > > I tried it, and it works: > > proxy-prefetching-limit="50"> > > ... > > > > Is that the correct way? Yes. And now this is equivalent to i.e. proxy prefetching is turned on by default and the default limit is 50. One can use the "proxy-prefetching-limit" attribute to change this setting, e.g. will set the limit to 200, will turn proxy prefetching off by default (however, this can be overriden by setting "proxy-prefetching-limit" to non-zero value for some classes and relations). Regards, Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AW: Character set mismatch error in Oracle
P6SPY ? It's dead easy to use; p6SPY is a "wrapper" jdbc driver. a) Ensure p6spy.jar is in the classpath, as well as the b) find spy.properties in the OJB distribution - it's about somewhere. Copy it, and place it on the classpath - actually, with the version of p6spy distributed with OJB, we've found that we often have to place it in the "current directory" e.g. tomcat/bin c) in spy.properties replace "realdriver=???" with "realdriver=oracle.jdbc.driver.OracleDriver" d) change the connection descriptor like this : And "bob's your uncle". Basically, all this does is change the jdbc descriptor to point to the p6spy driver, and the p6spy driver to point to oracle. So, all the jdbc calls are delgated to p6spy, which are then logged. It's wonderfully simple, and terrifically useful. More about p6spy can be found here : http://www.p6spy.com/ Note : the latest version currently available on the p6spy website appears to be terribly buggy; I suggest sticking to the one distributed with OJB. Cheers, Charles. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 27 October 2003 07:23 > To: OJB Users List > Subject: Re: AW: Character set mismatch error in Oracle > > > > > > > Could any one give me a hand on this one ? > > Patrick Reyes > - Forwarded by Patrick Reyes/CDS/CG/CAPITAL on 10/27/2003 08:22 AM > - > > > > Patrick Reyes > > >To: "OJB > Users List" <[EMAIL PROTECTED]> > > 10/23/2003 07:57 cc: "OJB > Users List" <[EMAIL PROTECTED]> > > AM Subject: Re: > AW: Character set mismatch error in Oracle(Document link: > Patrick Reyes) > > > > > > > > > > Yep, sorry I forgot to include this information here it is: > > isolation-level="read-uncommitted"> >jcd-alias="" > default-connection="true" > platform="Oracle" > jdbc-level="2.0" > driver="oracle.jdbc.driver.OracleDriver" > protocol="jdbc" > subprotocol="oracle:thin" > dbalias="@gvo2appd12:1521:EFAX817" > username="***" > password="***" > batch-mode="false" > > > >className="org.apache.ojb.broker.util.sequence.SequenceManager > HighLowImpl"> > > > > > - with which character set did you create your database > > The database was created by our DBA, but he is out for the > week :-( How do > I check this ? > > - how does the CREATE TABLE statement look like (esp. the > datatype in the > database) > > CREATE TABLE EFAX.MESSAGE > (ID INTEGER NOT NULL, >CONTENT NVARCHAR2(1) NOT NULL, >STATUS INTEGER NOT NULL, >CREATION_DATE DATE NOT NULL, >MODIFICATION_DATE DATE NOT NULL); > > - (well, and maybe the p6spy output of the actual statement > sent to the > database= > > If only I knew how to use p6spy I would ? Where can I find > doc on this tool > ? > > Thanks and regards, > > Patrick Reyes > > > > > > "Geigl > > > Maximilian, R235"To: "OJB > Users List" <[EMAIL PROTECTED]> > >(bcc: Patrick Reyes/CDS/CG/CAPITAL) > > @akdb.de>Subject: AW: > Character set mismatch error in Oracle > > > > > 10/22/2003 05:53 > > > PM > > > Please respond to > > > "OJB Users List" > >
Re: AW: Character set mismatch error in Oracle
Could any one give me a hand on this one ?
Patrick Reyes
- Forwarded by Patrick Reyes/CDS/CG/CAPITAL on 10/27/2003 08:22 AM
-
Patrick Reyes
To: "OJB Users List" <[EMAIL
PROTECTED]>
10/23/2003 07:57 cc: "OJB Users List" <[EMAIL
PROTECTED]>
AM Subject: Re: AW: Character set mismatch
error in Oracle(Document link: Patrick Reyes)
Yep, sorry I forgot to include this information here it is:
- with which character set did you create your database
The database was created by our DBA, but he is out for the week :-( How do
I check this ?
- how does the CREATE TABLE statement look like (esp. the datatype in the
database)
CREATE TABLE EFAX.MESSAGE
(ID INTEGER NOT NULL,
CONTENT NVARCHAR2(1) NOT NULL,
STATUS INTEGER NOT NULL,
CREATION_DATE DATE NOT NULL,
MODIFICATION_DATE DATE NOT NULL);
- (well, and maybe the p6spy output of the actual statement sent to the
database=
If only I knew how to use p6spy I would ? Where can I find doc on this tool
?
Thanks and regards,
Patrick Reyes
"Geigl
Maximilian, R235"To: "OJB Users List" <[EMAIL
PROTECTED]>
Subject: AW: Character set mismatch
error in Oracle
10/22/2003 05:53
PM
Please respond to
"OJB Users List"
Hi,
can you tell, which
- jdbc driver you use (THIN or the one that uses Oracle Net) - maybe the
connection
descriptor wourd be helpful
- with which character set did you create your database
- how does the CREATE TABLE statement look like (esp. the datatype in the
database)
- (well, and maybe the p6spy output of the actual statement sent to the
database=
Max
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Gesendet: Mittwoch, 22. Oktober 2003 15:38
> An: [EMAIL PROTECTED]
> Betreff: Character set mismatch error in Oracle
>
>
>
>
>
>
> I am trying to access an Oracle 8i DB via OJB.
>
> Here is my repository def:
>
>
>
>
>
>
>
>class="com.capgroup.mo.transport.Message"
> table="EFAX.MESSAGE"
> >
>name="id"
> column="ID"
> jdbc-type="INTEGER"
> primarykey="true"
> />
>name="content"
> column="CONTENT"
> jdbc-type="VARCHAR"
> />
>name="status"
> column="STATUS"
> jdbc-type="INTEGER"
> />
>name="creation_date"
> column="CREATION_DATE"
> jdbc-type="DATE"
> conversion =
> "org.apache.ojb.broker.accesslayer.conversions.JavaDate2SqlDat
> eFieldConversion"
>
> />
>name="modification_date"
> column="MODIFICATION_DATE"
> jdbc-type="DATE"
> conversion =
> "org.apache.ojb.broker.accesslayer.conversions.JavaDate2SqlDat
> eFieldConversion"
>
> />
>
>
>
> And here is my class:
>
> // Generated by impart OJB Generator
> // www.impart.ch [EMAIL PROTECTED]
> // created at 22 Oct 2003 12:37:30 GMT
>
> package com.capgroup.mo.transport;
>
> import java.util.Date;
> //import java.sql.*;
>
> public class Message
> {
>
> private Object content;
> private Date creation_date;
> private long id;
> private Date modification_date;
> private long status;
>
>
>
> public Object getContent()
> {
> return this.content;
> }
> public void setContent(Object param)
> {
> this.content = param;
> }
>
>
> public Date getCreation_date()
> {
> return this.creation_date;
> }
> public void setCreation_date(Date param)
> {
> this.creation_date = param;
> }
>
>
> public long getId()
> {
> return this.id;
> }
> public void setId(long param)
> {
> this.id = param;
> }
>
>
> public Date getModification_date()
> {
> return this.modification_date;
> }
> public void setModification_date(Date param)
> {
> this.modification_date = param;
> }
>
>
> public long getStatus()
> {
> return this.status;
> }
> public void setStatus(long param)
> {
> this.status = param;
> }
>
>
> public String toString(){
> return " [CONTENT] " + content + " [CREATI
Re: Any word on the next version?
Hi Clay, I think there is a consensus among the developers that we will have an additional RC5. RC5 will be the codefreezes base for 1.0. I think we need some more more work to reach a codefreeze state, at least some weeks. There is no scheduled date for it. For the time being I recommend to use the CVS head and to compile from source. Thomas Clay Mitchell wrote: Any idea when we might see rc5 or a real 1.0 release? I need a few things that are in the next version, like support for boolean types, and was wondering if there was a targetted date for it. Thanks! -Clay - 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]
