Re: Only one PB from second database
Bruno CROS wrote:
Yep, i 'm affraid that _pool.size() is always > than -1 !! (the
maxIdle), so
"shouldDestroy" is true, and no pool is added.
May be it's me . Someone can confirm this ?
Yep! The pool is always empty.
I would recommend first to try the connection-pool default settings
shipped with OJB (adapt maxActive is ok). These settings are well
tested. If this works for you start varying the default settings.
If you handle the "read-only" broker instances correctly (e.g. close it
immediately after use, ...) I don't have a clue why this freeze happens
- maybe a commons-pool issue.
By the way, I don't recommend to set logAbandoned="true" (when using
ConnectionFactoryDBCPImpl) particularly in production environment
because it's costly to trace connections. Each abandoned connection is
bug and should be fixed.
regards,
Armin
private void addObjectToPool(Object obj, boolean decrementNumActive)
throws Exception {
boolean success = true;
if(_testOnReturn && !(_factory.validateObject(obj))) {
success = false;
} else {
try {
_factory.passivateObject(obj);
} catch(Exception e) {
success = false;
}
}
boolean shouldDestroy = !success;
if (decrementNumActive) {
_numActive--;
}
if((_maxIdle >= 0) && (_pool.size() >= _maxIdle)) {
shouldDestroy = true;
} else if(success) {
_pool.addLast(new ObjectTimestampPair(obj));
}
notifyAll(); // _numActive has changed
if(shouldDestroy) {
try {
_factory.destroyObject(obj);
} catch(Exception e) {
// ignored
}
}
}
On 5/11/06, Armin Waibel <[EMAIL PROTECTED]> wrote:
Bruno CROS wrote:
> when MaxIdle is set to 0, it works well, and the 5 maxActive are
> sufficient.
> No freeze at all.
it's a moot point whether only one connection or five connections are
used when maxIdle is 0. I think that maxIdle=0 will immediately close
returned connections.
>
> The whenExhaustedAction block is well what i want, no error. And it
works
> with maxIdle set to 0.
>
> I don't see why no connection remaining in the pool leads to a
> serialization. Dead lock is a good assumption, it looks like that, but
if
> code only reads, i don't known at all how to produce dead lock.
A deadlock caused by the pool and and depended broker instances (one
broker wait for a result of another one or a broker leak), not a
database deadlock.
> I'm
> going to
> look at common-pool settings, if maxIdle is common-pool setting.
yep, maxIdle is a commons-pool setting. I would recommend to check the
source code.
http://jakarta.apache.org/commons/pool/cvs-usage.html
(currently the apache svn is down due a SVN-server problem last night,
so download the sources).
regards,
Armin
>
> regards
>
>
>
>
>
> On 5/11/06, Armin Waibel <[EMAIL PROTECTED]> wrote:
>>
>> Bruno CROS wrote:
>> > Hi Armin,
>> >
>> > autoCommit set to 1 does not avoid freeze. The fact is that database
is
>> > only
>> > used to be read, so rollbacks ( by disconnecting) will never be
long.
>> > autocommit is however set to 1 now. Thanks for the advice.
>> >
>> > I dont' known why it freezes when maxIdle set to -1 and why it does
not
>> > when
>> > maxIdle is set to 0. But if i well guess, 0 closes usable
connections,
>> > that's it ?! So it's not optimized.
>> >
>>
>> You enabled whenExhaustedAction="1" this mean that the pool blocks
till
>> a connection was returned. Max active connections is set to 5 this
isn't
>> much for a mulithreaded application. Maybe your application cause a
>> deadlock, five different broker instances exhaust the pool and another
>> broker instance try to lookup a connection but other broker instances
>> still not closed.
>> What happens when you set whenExhaustedAction="0"?
>>
>> I think if you set maxIdle=0 only one connection or none connections
>> will remain in the pool (maybe I'm wrong, I don't check commons-pool
>> sources) and all access is "serialized" by this.
>>
>> regards,
>> Armin
>>
>>
>> > Here's my well working conn setup
>> >
>> > Regards.
>> >
>> >
>> >> >maxActive="5"
>> >maxIdle="0"
>> >minIdle="2"
>> >maxWait="1000"
>> >whenExhaustedAction="1"
>> >
>> >validationQuery="SELECT CURRENT_TIMESTAMP"
>> >testOnBorrow="true"
>> >testOnReturn="false"
>> >testWhileIdle="true"
>> >timeBetweenEvictionRunsMillis="6"
>> >numTestsPerEvictionRun="2"
>> >minEvictableIdleTimeMillis="180"
>> >removedAbandonned="false"
>> >removeAbandonedTimeout="300"
>> >logAbandoned="true">
>> >
>> >
>> >
>> >
>> >
>> >
>> >> > attribute-value="5"/>
>> >
>> >
>> >> > attribute
Re: generate global uid's
Hi Dennis, Dennis Bekkering wrote: Hello all, I am almost there with regards to asynq data merging based upon GUID. What i am looking for now is a way to have a creationdate field in indirectiontables. I am not sure how to do this since it is all handled by OJB. If you need an additional field in indirection table you can't use non-decomposed m:n relation. The case is like this, a local server has records that are not present in the main server. It is either a new local record or a deleted global one. I can discover what it is if i know the last synqdate of the localserver. If the lastsynq date is after the creationdate of the local record then the global record is deleted and the local record should also be deleted, if the lastsynq is before the creationdate then the local record is new and should be send to the main server. I can control every record's creationdate except for the indirecttable ones. To make this possible (OJB populate an additional timestamp column in indirection table on insert) with non-decomposed m:n relation you have to modify/extend OJB. If each indirection table has a additional column TIME_STAMP you can modify the creation of m:n insert statement. In this case you have to implement your own SqlGenerator class (extend existing default and override #getInsertMNStatement) and MtoNBroker class (override insert methods)... this will be complicated. I don't know an easy solution for your problem. If the timeframe between two synchronization calls is greater then seconds and you don't need millisecond precision of timestamp values you can try to update the indirection table entries after OJB insert/update the entries. You can use plain SQL or you can define a persistence capable object for each indirection table and after insert/update you request all rows with empty timestamp column, set the timestamp and update the indirection table objects. regards, Armin regards, Dennis 2006/4/25, Armin Waibel <[EMAIL PROTECTED]>: Hi Dennis, to use OJB's auto-increment feature (automatic assignment of PK's) you have to implement a SequenceManager based on class GUIDFactory. Simply extend AbstractSequenceManager and override public Object getUniqueValue(...) Implement protected int getUniqueId(...) and throw exception within this method (see SequenceManagerMSSQLGuidImpl). regards, Armin Dennis Bekkering wrote: > great, thanks! > > 2006/4/24, Thomas Mahler <[EMAIL PROTECTED]>: >> Hi Dennis, >> >> org.apache.ojb.broker.util.GUIDFactory produces GUIDs that are unique >> across different VMs. >> >> cheers, >> Thomas >> >> Dennis Bekkering wrote: >>> Hello all, >>> >>> I have a situation where i frequently have to merge data from different >>> databases. Uptill now every database has it's own sequence. That means >> that >>> i cannot merge the data blindly because two records with the same id >> might >>> not be the same record. I am thinking of switching from int id's to >> varchar >>> UID's. Does ojb support such mechanism in an offline manner, so that the >> two >>> servers do not need to communicate with each other. If all id's are >> globally >>> unique i can blindly merge data without the danger of overwriting stuff. >> If >>> ojb does not offer this out of the box then does anybody now a way to >>> generate UID's across systems. Within one system I use >>> java.rmi.server.UID().toString() >>> but i dont know how unique that is across different VM's. >>> >>> Cheers, >>> Dennis >>> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > -- > mvg, > Dennis > - 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: Only one PB from second database
Oops, it's me.
Sorry
On 5/11/06, Bruno CROS <[EMAIL PROTECTED]> wrote:
Yep, i 'm affraid that _pool.size() is always > than -1 !! (the maxIdle),
so "shouldDestroy" is true, and no pool is added.
May be it's me . Someone can confirm this ?
private void addObjectToPool(Object obj, boolean decrementNumActive)
throws Exception {
boolean success = true;
if(_testOnReturn && !(_factory.validateObject(obj))) {
success = false;
} else {
try {
_factory.passivateObject(obj);
} catch(Exception e) {
success = false;
}
}
boolean shouldDestroy = !success;
if (decrementNumActive) {
_numActive--;
}
if((_maxIdle >= 0) && (_pool.size() >= _maxIdle)) {
shouldDestroy = true;
} else if(success) {
_pool.addLast(new ObjectTimestampPair(obj));
}
notifyAll(); // _numActive has changed
if(shouldDestroy) {
try {
_factory.destroyObject(obj);
} catch(Exception e) {
// ignored
}
}
}
On 5/11/06, Armin Waibel <[EMAIL PROTECTED]> wrote:
>
>
>
> Bruno CROS wrote:
> > when MaxIdle is set to 0, it works well, and the 5 maxActive are
> > sufficient.
> > No freeze at all.
>
> it's a moot point whether only one connection or five connections are
> used when maxIdle is 0. I think that maxIdle=0 will immediately close
> returned connections.
>
>
> >
> > The whenExhaustedAction block is well what i want, no error. And it
> works
> > with maxIdle set to 0.
> >
> > I don't see why no connection remaining in the pool leads to a
> > serialization. Dead lock is a good assumption, it looks like that, but
> if
> > code only reads, i don't known at all how to produce dead lock.
>
> A deadlock caused by the pool and and depended broker instances (one
> broker wait for a result of another one or a broker leak), not a
> database deadlock.
>
> > I'm
> > going to
> > look at common-pool settings, if maxIdle is common-pool setting.
>
> yep, maxIdle is a commons-pool setting. I would recommend to check the
> source code.
> http://jakarta.apache.org/commons/pool/cvs-usage.html
> (currently the apache svn is down due a SVN-server problem last night,
> so download the sources).
>
> regards,
> Armin
>
> >
> > regards
> >
> >
> >
> >
> >
> > On 5/11/06, Armin Waibel <[EMAIL PROTECTED]> wrote:
> >>
> >> Bruno CROS wrote:
> >> > Hi Armin,
> >> >
> >> > autoCommit set to 1 does not avoid freeze. The fact is that
> database is
> >> > only
> >> > used to be read, so rollbacks ( by disconnecting) will never be
> long.
> >> > autocommit is however set to 1 now. Thanks for the advice.
> >> >
> >> > I dont' known why it freezes when maxIdle set to -1 and why it does
> not
> >> > when
> >> > maxIdle is set to 0. But if i well guess, 0 closes usable
> connections,
> >> > that's it ?! So it's not optimized.
> >> >
> >>
> >> You enabled whenExhaustedAction="1" this mean that the pool blocks
> till
> >> a connection was returned. Max active connections is set to 5 this
> isn't
> >> much for a mulithreaded application. Maybe your application cause a
> >> deadlock, five different broker instances exhaust the pool and
> another
> >> broker instance try to lookup a connection but other broker instances
> >> still not closed.
> >> What happens when you set whenExhaustedAction="0"?
> >>
> >> I think if you set maxIdle=0 only one connection or none connections
> >> will remain in the pool (maybe I'm wrong, I don't check commons-pool
> >> sources) and all access is "serialized" by this.
> >>
> >> regards,
> >> Armin
> >>
> >>
> >> > Here's my well working conn setup
> >> >
> >> > Regards.
> >> >
> >> >
> >> > >> >maxActive="5"
> >> >maxIdle="0"
> >> >minIdle="2"
> >> >maxWait="1000"
> >> >whenExhaustedAction="1"
> >> >
> >> >validationQuery="SELECT CURRENT_TIMESTAMP"
> >> >testOnBorrow="true"
> >> >testOnReturn="false"
> >> >testWhileIdle="true"
> >> >timeBetweenEvictionRunsMillis="6"
> >> >numTestsPerEvictionRun="2"
> >> >minEvictableIdleTimeMillis="180"
> >> >removedAbandonned="false"
> >> >removeAbandonedTimeout="300"
> >> >logAbandoned="true">
> >> >
> >> >
> >> > attribute-value="0"/>
> >> >
> >> >
> >> >
> >> > >> > attribute-value="5"/>
> >> >
> >> >
> >> > >> > attribute-value="false"/>
> >> > >> > attribute-value="10"/>
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > On 5/6/06, Armin Waibel <[EMAIL PROTECTED] > wrote:
> >> >>
> >> >> Hi Bruno,
> >> >>
> >> >> Bruno CROS wrote:
> >> >> > Hi Armin,
> >> >> >
> >> >> > In fact, i l
Re: Only one PB from second database
Yep, i 'm affraid that _pool.size() is always > than -1 !! (the maxIdle), so
"shouldDestroy" is true, and no pool is added.
May be it's me . Someone can confirm this ?
private void addObjectToPool(Object obj, boolean decrementNumActive)
throws Exception {
boolean success = true;
if(_testOnReturn && !(_factory.validateObject(obj))) {
success = false;
} else {
try {
_factory.passivateObject(obj);
} catch(Exception e) {
success = false;
}
}
boolean shouldDestroy = !success;
if (decrementNumActive) {
_numActive--;
}
if((_maxIdle >= 0) && (_pool.size() >= _maxIdle)) {
shouldDestroy = true;
} else if(success) {
_pool.addLast(new ObjectTimestampPair(obj));
}
notifyAll(); // _numActive has changed
if(shouldDestroy) {
try {
_factory.destroyObject(obj);
} catch(Exception e) {
// ignored
}
}
}
On 5/11/06, Armin Waibel <[EMAIL PROTECTED]> wrote:
Bruno CROS wrote:
> when MaxIdle is set to 0, it works well, and the 5 maxActive are
> sufficient.
> No freeze at all.
it's a moot point whether only one connection or five connections are
used when maxIdle is 0. I think that maxIdle=0 will immediately close
returned connections.
>
> The whenExhaustedAction block is well what i want, no error. And it
works
> with maxIdle set to 0.
>
> I don't see why no connection remaining in the pool leads to a
> serialization. Dead lock is a good assumption, it looks like that, but
if
> code only reads, i don't known at all how to produce dead lock.
A deadlock caused by the pool and and depended broker instances (one
broker wait for a result of another one or a broker leak), not a
database deadlock.
> I'm
> going to
> look at common-pool settings, if maxIdle is common-pool setting.
yep, maxIdle is a commons-pool setting. I would recommend to check the
source code.
http://jakarta.apache.org/commons/pool/cvs-usage.html
(currently the apache svn is down due a SVN-server problem last night,
so download the sources).
regards,
Armin
>
> regards
>
>
>
>
>
> On 5/11/06, Armin Waibel <[EMAIL PROTECTED]> wrote:
>>
>> Bruno CROS wrote:
>> > Hi Armin,
>> >
>> > autoCommit set to 1 does not avoid freeze. The fact is that database
is
>> > only
>> > used to be read, so rollbacks ( by disconnecting) will never be long.
>> > autocommit is however set to 1 now. Thanks for the advice.
>> >
>> > I dont' known why it freezes when maxIdle set to -1 and why it does
not
>> > when
>> > maxIdle is set to 0. But if i well guess, 0 closes usable
connections,
>> > that's it ?! So it's not optimized.
>> >
>>
>> You enabled whenExhaustedAction="1" this mean that the pool blocks till
>> a connection was returned. Max active connections is set to 5 this
isn't
>> much for a mulithreaded application. Maybe your application cause a
>> deadlock, five different broker instances exhaust the pool and another
>> broker instance try to lookup a connection but other broker instances
>> still not closed.
>> What happens when you set whenExhaustedAction="0"?
>>
>> I think if you set maxIdle=0 only one connection or none connections
>> will remain in the pool (maybe I'm wrong, I don't check commons-pool
>> sources) and all access is "serialized" by this.
>>
>> regards,
>> Armin
>>
>>
>> > Here's my well working conn setup
>> >
>> > Regards.
>> >
>> >
>> >> >maxActive="5"
>> >maxIdle="0"
>> >minIdle="2"
>> >maxWait="1000"
>> >whenExhaustedAction="1"
>> >
>> >validationQuery="SELECT CURRENT_TIMESTAMP"
>> >testOnBorrow="true"
>> >testOnReturn="false"
>> >testWhileIdle="true"
>> >timeBetweenEvictionRunsMillis="6"
>> >numTestsPerEvictionRun="2"
>> >minEvictableIdleTimeMillis="180"
>> >removedAbandonned="false"
>> >removeAbandonedTimeout="300"
>> >logAbandoned="true">
>> >
>> >
>> >
>> >
>> >
>> >
>> >> > attribute-value="5"/>
>> >
>> >
>> >> > attribute-value="false"/>
>> >> > attribute-value="10"/>
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On 5/6/06, Armin Waibel <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Hi Bruno,
>> >>
>> >> Bruno CROS wrote:
>> >> > Hi Armin,
>> >> >
>> >> > In fact, i looked at the DB connections in the DB console. It was
a
>> bad
>> >> > idea, because connection disappear !! I looked with netstat -a ,
and
>> i
>> >> saw
>> >> > several sockets/connections...
>> >> >
>> >> > Well, i was experiencing some freezes with these connections with
a
>> >> pool
>> >> > setup maxActive set to -1. I didn't find any documentation on that
>> >> value.
>> >>
>> >> Both Con
Re: Only one PB from second database
No idea. All is ok on paper!
http://jakarta.apache.org/commons/pool/apidocs/org/apache/commons/pool/impl/GenericObjectPool.html
On 5/11/06, Bruno CROS <[EMAIL PROTECTED]> wrote:
when MaxIdle is set to 0, it works well, and the 5 maxActive are
sufficient. No freeze at all.
The whenExhaustedAction block is well what i want, no error. And it works
with maxIdle set to 0.
I don't see why no connection remaining in the pool leads to a
serialization. Dead lock is a good assumption, it looks like that, but if
code only reads, i don't known at all how to produce dead lock. I'm going to
look at common-pool settings, if maxIdle is common-pool setting.
regards
On 5/11/06, Armin Waibel <[EMAIL PROTECTED]> wrote:
>
> Bruno CROS wrote:
> > Hi Armin,
> >
> > autoCommit set to 1 does not avoid freeze. The fact is that database
> is
> > only
> > used to be read, so rollbacks ( by disconnecting) will never be long.
> > autocommit is however set to 1 now. Thanks for the advice.
> >
> > I dont' known why it freezes when maxIdle set to -1 and why it does
> not
> > when
> > maxIdle is set to 0. But if i well guess, 0 closes usable connections,
> > that's it ?! So it's not optimized.
> >
>
> You enabled whenExhaustedAction="1" this mean that the pool blocks till
> a connection was returned. Max active connections is set to 5 this isn't
> much for a mulithreaded application. Maybe your application cause a
> deadlock, five different broker instances exhaust the pool and another
> broker instance try to lookup a connection but other broker instances
> still not closed.
> What happens when you set whenExhaustedAction="0"?
>
> I think if you set maxIdle=0 only one connection or none connections
> will remain in the pool (maybe I'm wrong, I don't check commons-pool
> sources) and all access is "serialized" by this.
>
> regards,
> Armin
>
>
> > Here's my well working conn setup
> >
> > Regards.
> >
> >
> > >maxActive="5"
> >maxIdle="0"
> >minIdle="2"
> >maxWait="1000"
> >whenExhaustedAction="1"
> >
> >validationQuery="SELECT CURRENT_TIMESTAMP"
> >testOnBorrow="true"
> >testOnReturn="false"
> >testWhileIdle="true"
> >timeBetweenEvictionRunsMillis="6"
> >numTestsPerEvictionRun="2"
> >minEvictableIdleTimeMillis="180"
> >removedAbandonned="false"
> >removeAbandonedTimeout="300"
> >logAbandoned="true">
> >
> >
> >
> >
> >
> >
> > > attribute-value="5"/>
> >
> >
> > > attribute-value="false"/>
> > > attribute-value="10"/>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On 5/6/06, Armin Waibel <[EMAIL PROTECTED]> wrote:
> >>
> >> Hi Bruno,
> >>
> >> Bruno CROS wrote:
> >> > Hi Armin,
> >> >
> >> > In fact, i looked at the DB connections in the DB console. It was a
> bad
> >> > idea, because connection disappear !! I looked with netstat -a ,
> and i
> >> saw
> >> > several sockets/connections...
> >> >
> >> > Well, i was experiencing some freezes with these connections with a
> >> pool
> >> > setup maxActive set to -1. I didn't find any documentation on that
> >> value.
> >>
> >> Both ConnectionFactoryPooledImpl and ConnectionFactoryDBCPImpl use
> >> commons-pool to manage connections. There you can find details about
> the
> >> settings
> >> http://jakarta.apache.org/commons/pool/apidocs/index.html
> >>
> >> I would recommend to set maxActive connections at most to the maximal
> >> connections provided by your database server.
> >>
> >>
> >> > What i known is that, when i put 0 (no limit), it seems there is no
> >> more
> >> > freeze.
> >> >
> >>
> >> I think there is a typo in documentation. For unlimited connection
> pool
> >> you have to set -1.
> >>
> >>
http://jakarta.apache.org/commons/pool/apidocs/org/apache/commons/pool/impl/GenericObjectPool.html
>
> >>
> >> Will fix this till next release.
> >>
> >> In your jdbc-connection-descriptor (posted some time ago) you set
> >> useAutoCommit="0". In this case you have to enable autoCommit 'false'
> in
> >> your jdbc-driver configuration setup, else you will run into rollback
> >> hassle (if autoCommit is 'true' for connections).
> >>
> >> regards,
> >> Armin
> >>
> >> > Can you ligth up me about that.
> >> >
> >> > Thanks.
> >> >
> >> > Regards.
> >> >
> >> >
> >> >
> >> > On 5/5/06, Armin Waibel <[EMAIL PROTECTED] > wrote:
> >> >>
> >> >> Hi Bruno,
> >> >>
> >> >> Bruno CROS wrote:
> >> >> > Hi,
> >> >> >
> >> >> > I have a strange behaviour about the second database i use. It
> >> seems
> >> >> that
> >> >> > using "broker =
> >> >> > PersistenceBrokerFactory.createPersistenceBroker("rushDb");"
> >> >> > always return the same broker/connection.
> >> >> >
> >> >> > My connection pool is setup as it have to keep 2 idle
> connections
> >> >> > available, a
Re: Only one PB from second database
Bruno CROS wrote:
when MaxIdle is set to 0, it works well, and the 5 maxActive are
sufficient.
No freeze at all.
it's a moot point whether only one connection or five connections are
used when maxIdle is 0. I think that maxIdle=0 will immediately close
returned connections.
The whenExhaustedAction block is well what i want, no error. And it works
with maxIdle set to 0.
I don't see why no connection remaining in the pool leads to a
serialization. Dead lock is a good assumption, it looks like that, but if
code only reads, i don't known at all how to produce dead lock.
A deadlock caused by the pool and and depended broker instances (one
broker wait for a result of another one or a broker leak), not a
database deadlock.
I'm
going to
look at common-pool settings, if maxIdle is common-pool setting.
yep, maxIdle is a commons-pool setting. I would recommend to check the
source code.
http://jakarta.apache.org/commons/pool/cvs-usage.html
(currently the apache svn is down due a SVN-server problem last night,
so download the sources).
regards,
Armin
regards
On 5/11/06, Armin Waibel <[EMAIL PROTECTED]> wrote:
Bruno CROS wrote:
> Hi Armin,
>
> autoCommit set to 1 does not avoid freeze. The fact is that database is
> only
> used to be read, so rollbacks ( by disconnecting) will never be long.
> autocommit is however set to 1 now. Thanks for the advice.
>
> I dont' known why it freezes when maxIdle set to -1 and why it does not
> when
> maxIdle is set to 0. But if i well guess, 0 closes usable connections,
> that's it ?! So it's not optimized.
>
You enabled whenExhaustedAction="1" this mean that the pool blocks till
a connection was returned. Max active connections is set to 5 this isn't
much for a mulithreaded application. Maybe your application cause a
deadlock, five different broker instances exhaust the pool and another
broker instance try to lookup a connection but other broker instances
still not closed.
What happens when you set whenExhaustedAction="0"?
I think if you set maxIdle=0 only one connection or none connections
will remain in the pool (maybe I'm wrong, I don't check commons-pool
sources) and all access is "serialized" by this.
regards,
Armin
> Here's my well working conn setup
>
> Regards.
>
>
>maxActive="5"
>maxIdle="0"
>minIdle="2"
>maxWait="1000"
>whenExhaustedAction="1"
>
>validationQuery="SELECT CURRENT_TIMESTAMP"
>testOnBorrow="true"
>testOnReturn="false"
>testWhileIdle="true"
>timeBetweenEvictionRunsMillis="6"
>numTestsPerEvictionRun="2"
>minEvictableIdleTimeMillis="180"
>removedAbandonned="false"
>removeAbandonedTimeout="300"
>logAbandoned="true">
>
>
>
>
>
>
> attribute-value="5"/>
>
>
> attribute-value="false"/>
> attribute-value="10"/>
>
>
>
>
>
>
>
>
>
>
> On 5/6/06, Armin Waibel <[EMAIL PROTECTED]> wrote:
>>
>> Hi Bruno,
>>
>> Bruno CROS wrote:
>> > Hi Armin,
>> >
>> > In fact, i looked at the DB connections in the DB console. It was a
bad
>> > idea, because connection disappear !! I looked with netstat -a , and
i
>> saw
>> > several sockets/connections...
>> >
>> > Well, i was experiencing some freezes with these connections with a
>> pool
>> > setup maxActive set to -1. I didn't find any documentation on that
>> value.
>>
>> Both ConnectionFactoryPooledImpl and ConnectionFactoryDBCPImpl use
>> commons-pool to manage connections. There you can find details about
the
>> settings
>> http://jakarta.apache.org/commons/pool/apidocs/index.html
>>
>> I would recommend to set maxActive connections at most to the maximal
>> connections provided by your database server.
>>
>>
>> > What i known is that, when i put 0 (no limit), it seems there is no
>> more
>> > freeze.
>> >
>>
>> I think there is a typo in documentation. For unlimited connection
pool
>> you have to set -1.
>>
>>
http://jakarta.apache.org/commons/pool/apidocs/org/apache/commons/pool/impl/GenericObjectPool.html
>>
>> Will fix this till next release.
>>
>> In your jdbc-connection-descriptor (posted some time ago) you set
>> useAutoCommit="0". In this case you have to enable autoCommit 'false'
in
>> your jdbc-driver configuration setup, else you will run into rollback
>> hassle (if autoCommit is 'true' for connections).
>>
>> regards,
>> Armin
>>
>> > Can you ligth up me about that.
>> >
>> > Thanks.
>> >
>> > Regards.
>> >
>> >
>> >
>> > On 5/5/06, Armin Waibel <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Hi Bruno,
>> >>
>> >> Bruno CROS wrote:
>> >> > Hi,
>> >> >
>> >> > I have a strange behaviour about the second database i use. It
>> seems
>> >> that
>> >> > using "broker =
>> >> > PersistenceBrokerFactory.createPersistenceBroker("rushDb");"
>> >> > always return the sa
Re: Only one PB from second database
when MaxIdle is set to 0, it works well, and the 5 maxActive are sufficient.
No freeze at all.
The whenExhaustedAction block is well what i want, no error. And it works
with maxIdle set to 0.
I don't see why no connection remaining in the pool leads to a
serialization. Dead lock is a good assumption, it looks like that, but if
code only reads, i don't known at all how to produce dead lock. I'm going to
look at common-pool settings, if maxIdle is common-pool setting.
regards
On 5/11/06, Armin Waibel <[EMAIL PROTECTED]> wrote:
Bruno CROS wrote:
> Hi Armin,
>
> autoCommit set to 1 does not avoid freeze. The fact is that database is
> only
> used to be read, so rollbacks ( by disconnecting) will never be long.
> autocommit is however set to 1 now. Thanks for the advice.
>
> I dont' known why it freezes when maxIdle set to -1 and why it does not
> when
> maxIdle is set to 0. But if i well guess, 0 closes usable connections,
> that's it ?! So it's not optimized.
>
You enabled whenExhaustedAction="1" this mean that the pool blocks till
a connection was returned. Max active connections is set to 5 this isn't
much for a mulithreaded application. Maybe your application cause a
deadlock, five different broker instances exhaust the pool and another
broker instance try to lookup a connection but other broker instances
still not closed.
What happens when you set whenExhaustedAction="0"?
I think if you set maxIdle=0 only one connection or none connections
will remain in the pool (maybe I'm wrong, I don't check commons-pool
sources) and all access is "serialized" by this.
regards,
Armin
> Here's my well working conn setup
>
> Regards.
>
>
>maxActive="5"
>maxIdle="0"
>minIdle="2"
>maxWait="1000"
>whenExhaustedAction="1"
>
>validationQuery="SELECT CURRENT_TIMESTAMP"
>testOnBorrow="true"
>testOnReturn="false"
>testWhileIdle="true"
>timeBetweenEvictionRunsMillis="6"
>numTestsPerEvictionRun="2"
>minEvictableIdleTimeMillis="180"
>removedAbandonned="false"
>removeAbandonedTimeout="300"
>logAbandoned="true">
>
>
>
>
>
>
> attribute-value="5"/>
>
>
> attribute-value="false"/>
> attribute-value="10"/>
>
>
>
>
>
>
>
>
>
>
> On 5/6/06, Armin Waibel <[EMAIL PROTECTED]> wrote:
>>
>> Hi Bruno,
>>
>> Bruno CROS wrote:
>> > Hi Armin,
>> >
>> > In fact, i looked at the DB connections in the DB console. It was a
bad
>> > idea, because connection disappear !! I looked with netstat -a , and
i
>> saw
>> > several sockets/connections...
>> >
>> > Well, i was experiencing some freezes with these connections with a
>> pool
>> > setup maxActive set to -1. I didn't find any documentation on that
>> value.
>>
>> Both ConnectionFactoryPooledImpl and ConnectionFactoryDBCPImpl use
>> commons-pool to manage connections. There you can find details about
the
>> settings
>> http://jakarta.apache.org/commons/pool/apidocs/index.html
>>
>> I would recommend to set maxActive connections at most to the maximal
>> connections provided by your database server.
>>
>>
>> > What i known is that, when i put 0 (no limit), it seems there is no
>> more
>> > freeze.
>> >
>>
>> I think there is a typo in documentation. For unlimited connection pool
>> you have to set -1.
>>
>>
http://jakarta.apache.org/commons/pool/apidocs/org/apache/commons/pool/impl/GenericObjectPool.html
>>
>> Will fix this till next release.
>>
>> In your jdbc-connection-descriptor (posted some time ago) you set
>> useAutoCommit="0". In this case you have to enable autoCommit 'false'
in
>> your jdbc-driver configuration setup, else you will run into rollback
>> hassle (if autoCommit is 'true' for connections).
>>
>> regards,
>> Armin
>>
>> > Can you ligth up me about that.
>> >
>> > Thanks.
>> >
>> > Regards.
>> >
>> >
>> >
>> > On 5/5/06, Armin Waibel <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Hi Bruno,
>> >>
>> >> Bruno CROS wrote:
>> >> > Hi,
>> >> >
>> >> > I have a strange behaviour about the second database i use. It
>> seems
>> >> that
>> >> > using "broker =
>> >> > PersistenceBrokerFactory.createPersistenceBroker("rushDb");"
>> >> > always return the same broker/connection.
>> >> >
>> >> > My connection pool is setup as it have to keep 2 idle connections
>> >> > available, and it never occured. Still only one.
>> >> >
>> >> > How can i use several connection in this case?
>> >> >
>> >> > Note that this database is not not use to update datas. No
>> transaction
>> >> are
>> >> > used on it.
>> >> >
>> >>
>> >> how do you test this behavior? Please setup a test and lookup for
two
>> PB
>> >> instances at the same time:
>> >>
>> >> broker_A = PersistenceBrokerFactory.createPersistenceBroker
("rushDb");
>> >> broker_B = PersistenceBrokerFactory.createPersistence
Re: Intermitter error ...
Hi Armin,
My broker factory is:
PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl
Connection factory class is:
ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl
Persistence broker pool settings are:
maxActive=100
maxIdle=-1
maxWait=2000
timeBetweenEvictionRunsMillis=-1
minEvictableIdleTimeMillis=100
whenExhaustedAction=2
My jdbc connection descriptor is:
Even after using clearCache() i run into this issue. How do I solve the null
pointers?
Coming to the rollback issue, I use the same broker through out for storage and
this broker is obtained after the UserTransaction is started.
Thanks for your help.
-Vamsi
- Original Message
From: Armin Waibel <[EMAIL PROTECTED]>
To: OJB Users List
Sent: Thursday, May 11, 2006 1:17:00 PM
Subject: Re: Intermitter error ...
Vamsi Atluri wrote:
> Hi Armin,
>
> I am using OJB1.0.1 on WSAD 5.1 using JDK1.3.1. I have a simple table of the
> form:
>
> TABLE: BOOK_VERSION_DEF
>
> BOOK_IDINTEGER (PK)
> BOOK_VERSION_IDINTEGER (PK)
> CREATION_DATEDATE
>
> And my query code is like this:
>
> Criteria bookVersionCriteria = new Criteria();
> bookVersionCriteria.addEqualTo("bookId", Integer.valueOf("1"));
> QueryByCriteria bookVersionQuery = new QueryByCriteria(BookVersionDef.class,
> bookVersionCriteria);
> Collection bookVersionDefs = broker.getCollectionByQuery(bookVersionQuery);
>
> It is a very straight forward case. As for threads, I am using WebSphere's
> DataSource, so I am guessing there is on PB per thread. Also, if I do
> broker.clearCache() just before running the query, I don't run into this
> problem. I don't know if it solved it, but as the problem is intermittent, I
> am not sure if broker.clearCache() fixed it.
>
Strange! The posted stack trace indicate that you work on a closed/not
open PB instance because
[5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at
java.lang.NullPointerException.(NullPointerException.java:60)
> [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getClassDescriptor(PersistenceBrokerImpl.java)
method PB.getClassDescriptor(...) seems to cause the NPE. The method
itself does:
public ClassDescriptor getClassDescriptor(Class clazz) throws
PersistenceBrokerException
{
return descriptorRepository.getDescriptorFor(clazz);
}
and 'descriptorRepository' is only null when PB instance is closed.
Which PersistenceBrokerFactory do you use?
> Now, I have one more question. If I have a process that does multiple
> broker.store()s
> within a UserTransaction boundary, if I do a broker.clearCache() before each
> store()
> call, if there is a roll back will all db actions be rolled back?
>
If you use the same broker instance (or use datasources in managed
environment) and the broker instance was created after the UT starts - yes.
The synchronization of the cache depends on the used
implementation/configuration.
regards,
Armin
> -Vamsi
>
> - Original Message
> From: Armin Waibel <[EMAIL PROTECTED]>
> To: OJB Users List
> Sent: Thursday, May 11, 2006 10:49:51 AM
> Subject: Re: Intermitter error ...
>
>
> Hi Vamsi,
>
> could post more details of the used OJB version and how you are using
> OJB? Could it be a concurrency issue, is it guaranteed that each thread
> use it's own PB instance?
>
> regards,
> Armin
>
> Vamsi Atluri wrote:
>> Hello all,
>>
>> I am getting this error when I am doing a broker.getCollectionByQuery() very
>> intermittently. The same piece of code works some times and fails some times
>> with this error:
>>
>> [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R
>> java.lang.NullPointerException
>> [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at
>> java.lang.Throwable.(Throwable.java)
>> [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at
>> java.lang.Throwable.(Throwable.java)
>> [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at
>> java.lang.NullPointerException.(NullPointerException.java:60)
>> [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at
>> org.apache.ojb.broker.core.PersistenceBrokerImpl.getClassDescriptor(PersistenceBrokerImpl.java)
>>
>> [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at
>> org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java)
>>
>> [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at
>> org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java)
>>
>> [5/11/06 10:02:15:508 EDT] 24df24df SystemErr R at
>> org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:253)
>>
>> [5/11/06 10:02:15:508 EDT] 24df24df SystemErr R at
>> org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:1217)
>>
>> [5/11/06 10:02:15:508 EDT] 24df24df SystemErr R at
>> org.apache.ojb.broker
Re: Only one PB from second database
Bruno CROS wrote:
Hi Armin,
autoCommit set to 1 does not avoid freeze. The fact is that database is
only
used to be read, so rollbacks ( by disconnecting) will never be long.
autocommit is however set to 1 now. Thanks for the advice.
I dont' known why it freezes when maxIdle set to -1 and why it does not
when
maxIdle is set to 0. But if i well guess, 0 closes usable connections,
that's it ?! So it's not optimized.
You enabled whenExhaustedAction="1" this mean that the pool blocks till
a connection was returned. Max active connections is set to 5 this isn't
much for a mulithreaded application. Maybe your application cause a
deadlock, five different broker instances exhaust the pool and another
broker instance try to lookup a connection but other broker instances
still not closed.
What happens when you set whenExhaustedAction="0"?
I think if you set maxIdle=0 only one connection or none connections
will remain in the pool (maybe I'm wrong, I don't check commons-pool
sources) and all access is "serialized" by this.
regards,
Armin
Here's my well working conn setup
Regards.
On 5/6/06, Armin Waibel <[EMAIL PROTECTED]> wrote:
Hi Bruno,
Bruno CROS wrote:
> Hi Armin,
>
> In fact, i looked at the DB connections in the DB console. It was a bad
> idea, because connection disappear !! I looked with netstat -a , and i
saw
> several sockets/connections...
>
> Well, i was experiencing some freezes with these connections with a
pool
> setup maxActive set to -1. I didn't find any documentation on that
value.
Both ConnectionFactoryPooledImpl and ConnectionFactoryDBCPImpl use
commons-pool to manage connections. There you can find details about the
settings
http://jakarta.apache.org/commons/pool/apidocs/index.html
I would recommend to set maxActive connections at most to the maximal
connections provided by your database server.
> What i known is that, when i put 0 (no limit), it seems there is no
more
> freeze.
>
I think there is a typo in documentation. For unlimited connection pool
you have to set -1.
http://jakarta.apache.org/commons/pool/apidocs/org/apache/commons/pool/impl/GenericObjectPool.html
Will fix this till next release.
In your jdbc-connection-descriptor (posted some time ago) you set
useAutoCommit="0". In this case you have to enable autoCommit 'false' in
your jdbc-driver configuration setup, else you will run into rollback
hassle (if autoCommit is 'true' for connections).
regards,
Armin
> Can you ligth up me about that.
>
> Thanks.
>
> Regards.
>
>
>
> On 5/5/06, Armin Waibel <[EMAIL PROTECTED]> wrote:
>>
>> Hi Bruno,
>>
>> Bruno CROS wrote:
>> > Hi,
>> >
>> > I have a strange behaviour about the second database i use. It
seems
>> that
>> > using "broker =
>> > PersistenceBrokerFactory.createPersistenceBroker("rushDb");"
>> > always return the same broker/connection.
>> >
>> > My connection pool is setup as it have to keep 2 idle connections
>> > available, and it never occured. Still only one.
>> >
>> > How can i use several connection in this case?
>> >
>> > Note that this database is not not use to update datas. No
transaction
>> are
>> > used on it.
>> >
>>
>> how do you test this behavior? Please setup a test and lookup for two
PB
>> instances at the same time:
>>
>> broker_A = PersistenceBrokerFactory.createPersistenceBroker("rushDb");
>> broker_B = PersistenceBrokerFactory.createPersistenceBroker("rushDb");
>>
>> Are A and B really the same broker instances? If you execute a
query on
>> both broker instances (don't close the broker after it) and then
lookup
>> the Connection from A and B - are the connections the same?
>>
>> regards,
>> Armin
>>
>> >
>> > Thanks.
>> >
>> >
>> > Here's my connection setup.
>> >
>> >> > jcd-alias="rushDb"
>> > default-connection="false"
>> > platform="MsSQLServer"
>> > jdbc-level="2.0"
>> > driver="com.microsoft.jdbc.sqlserver.SQLServerDriver"
>> > protocol="JDBC"
>> > subprotocol="microsoft:sqlserver"
>> > dbalias="//xxx.x.x.x:1433"
>> > username=""
>> > password=""
>> > batch-mode="true"
>> >useAutoCommit="0"
>> >ignoreAutoCommitExceptions="true"
>> > >
>> >
>> > and pool setup :
>> >
>> >maxActive="5"
>> > maxIdle="-1"
>> >minIdle="2"
>> >maxWait="5000"
>> >whenExhaustedAction="2"
>> >
>> >validationQuery="SELECT CURRENT_TIMESTAMP"
>> >testOnBorrow="true"
>> >testOnReturn="false"
>> >testWhileIdle="true"
>> >timeBetweenEvictionRunsMillis="6"
>> > numTestsPerEvictionRun="2"
>> >minEvictableIdleTimeMillis="180"
>> >removedAbandonned="false"
>> >removeAbandonedTimeout="300"
>> >logAbandoned="true">
>> >
>>
>>
Re: Intermitter error ...
Vamsi Atluri wrote:
Hi Armin,
I am using OJB1.0.1 on WSAD 5.1 using JDK1.3.1. I have a simple table of the form:
TABLE: BOOK_VERSION_DEF
BOOK_IDINTEGER (PK)
BOOK_VERSION_IDINTEGER (PK)
CREATION_DATEDATE
And my query code is like this:
Criteria bookVersionCriteria = new Criteria();
bookVersionCriteria.addEqualTo("bookId", Integer.valueOf("1"));
QueryByCriteria bookVersionQuery = new QueryByCriteria(BookVersionDef.class,
bookVersionCriteria);
Collection bookVersionDefs = broker.getCollectionByQuery(bookVersionQuery);
It is a very straight forward case. As for threads, I am using WebSphere's DataSource, so I am guessing there is on PB per thread. Also, if I do broker.clearCache() just before running the query, I don't run into this problem. I don't know if it solved it, but as the problem is intermittent, I am not sure if broker.clearCache() fixed it.
Strange! The posted stack trace indicate that you work on a closed/not
open PB instance because
[5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at
java.lang.NullPointerException.(NullPointerException.java:60)
> [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getClassDescriptor(PersistenceBrokerImpl.java)
method PB.getClassDescriptor(...) seems to cause the NPE. The method
itself does:
public ClassDescriptor getClassDescriptor(Class clazz) throws
PersistenceBrokerException
{
return descriptorRepository.getDescriptorFor(clazz);
}
and 'descriptorRepository' is only null when PB instance is closed.
Which PersistenceBrokerFactory do you use?
Now, I have one more question. If I have a process that does multiple broker.store()s
within a UserTransaction boundary, if I do a broker.clearCache() before each store()
call, if there is a roll back will all db actions be rolled back?
If you use the same broker instance (or use datasources in managed
environment) and the broker instance was created after the UT starts - yes.
The synchronization of the cache depends on the used
implementation/configuration.
regards,
Armin
-Vamsi
- Original Message
From: Armin Waibel <[EMAIL PROTECTED]>
To: OJB Users List
Sent: Thursday, May 11, 2006 10:49:51 AM
Subject: Re: Intermitter error ...
Hi Vamsi,
could post more details of the used OJB version and how you are using
OJB? Could it be a concurrency issue, is it guaranteed that each thread
use it's own PB instance?
regards,
Armin
Vamsi Atluri wrote:
Hello all,
I am getting this error when I am doing a broker.getCollectionByQuery() very intermittently. The same piece of code works some times and fails some times with this error:
[5/11/06 10:02:15:498 EDT] 24df24df SystemErr R java.lang.NullPointerException
[5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at java.lang.Throwable.(Throwable.java)
[5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at java.lang.Throwable.(Throwable.java)
[5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at java.lang.NullPointerException.(NullPointerException.java:60)
[5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at org.apache.ojb.broker.core.PersistenceBrokerImpl.getClassDescriptor(PersistenceBrokerImpl.java)
[5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java)
[5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java)
[5/11/06 10:02:15:508 EDT] 24df24df SystemErr R at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:253)
[5/11/06 10:02:15:508 EDT] 24df24df SystemErr R at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:1217)
[5/11/06 10:02:15:508 EDT] 24df24df SystemErr R at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(DelegatingPersistenceBroker.java:338)
[5/11/06 10:02:15:508 EDT] 24df24df SystemErr R at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(DelegatingPersistenceBroker.java:338)
Does anybody have a clue why this might happen very intermittently? Since, it is intermittent it is very hard to debug.
-Vamsi
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: generate global uid's
Hello all, I am almost there with regards to asynq data merging based upon GUID. What i am looking for now is a way to have a creationdate field in indirectiontables. I am not sure how to do this since it is all handled by OJB. The case is like this, a local server has records that are not present in the main server. It is either a new local record or a deleted global one. I can discover what it is if i know the last synqdate of the localserver. If the lastsynq date is after the creationdate of the local record then the global record is deleted and the local record should also be deleted, if the lastsynq is before the creationdate then the local record is new and should be send to the main server. I can control every record's creationdate except for the indirecttable ones. regards, Dennis 2006/4/25, Armin Waibel <[EMAIL PROTECTED]>: Hi Dennis, to use OJB's auto-increment feature (automatic assignment of PK's) you have to implement a SequenceManager based on class GUIDFactory. Simply extend AbstractSequenceManager and override public Object getUniqueValue(...) Implement protected int getUniqueId(...) and throw exception within this method (see SequenceManagerMSSQLGuidImpl). regards, Armin Dennis Bekkering wrote: > great, thanks! > > 2006/4/24, Thomas Mahler <[EMAIL PROTECTED]>: >> Hi Dennis, >> >> org.apache.ojb.broker.util.GUIDFactory produces GUIDs that are unique >> across different VMs. >> >> cheers, >> Thomas >> >> Dennis Bekkering wrote: >>> Hello all, >>> >>> I have a situation where i frequently have to merge data from different >>> databases. Uptill now every database has it's own sequence. That means >> that >>> i cannot merge the data blindly because two records with the same id >> might >>> not be the same record. I am thinking of switching from int id's to >> varchar >>> UID's. Does ojb support such mechanism in an offline manner, so that the >> two >>> servers do not need to communicate with each other. If all id's are >> globally >>> unique i can blindly merge data without the danger of overwriting stuff. >> If >>> ojb does not offer this out of the box then does anybody now a way to >>> generate UID's across systems. Within one system I use >>> java.rmi.server.UID().toString() >>> but i dont know how unique that is across different VM's. >>> >>> Cheers, >>> Dennis >>> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > -- > mvg, > Dennis > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- mvg, Dennis
Re: Intermitter error ...
Hi Armin,
I am using OJB1.0.1 on WSAD 5.1 using JDK1.3.1. I have a simple table of the
form:
TABLE: BOOK_VERSION_DEF
BOOK_IDINTEGER (PK)
BOOK_VERSION_IDINTEGER (PK)
CREATION_DATEDATE
And my query code is like this:
Criteria bookVersionCriteria = new Criteria();
bookVersionCriteria.addEqualTo("bookId", Integer.valueOf("1"));
QueryByCriteria bookVersionQuery = new QueryByCriteria(BookVersionDef.class,
bookVersionCriteria);
Collection bookVersionDefs = broker.getCollectionByQuery(bookVersionQuery);
It is a very straight forward case. As for threads, I am using WebSphere's
DataSource, so I am guessing there is on PB per thread. Also, if I do
broker.clearCache() just before running the query, I don't run into this
problem. I don't know if it solved it, but as the problem is intermittent, I am
not sure if broker.clearCache() fixed it.
Now, I have one more question. If I have a process that does multiple
broker.store()s within a UserTransaction boundary, if I do a
broker.clearCache() before each store() call, if there is a roll back will all
db actions be rolled back?
-Vamsi
- Original Message
From: Armin Waibel <[EMAIL PROTECTED]>
To: OJB Users List
Sent: Thursday, May 11, 2006 10:49:51 AM
Subject: Re: Intermitter error ...
Hi Vamsi,
could post more details of the used OJB version and how you are using
OJB? Could it be a concurrency issue, is it guaranteed that each thread
use it's own PB instance?
regards,
Armin
Vamsi Atluri wrote:
> Hello all,
>
> I am getting this error when I am doing a broker.getCollectionByQuery() very
> intermittently. The same piece of code works some times and fails some times
> with this error:
>
> [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R
> java.lang.NullPointerException
> [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at
> java.lang.Throwable.(Throwable.java)
> [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at
> java.lang.Throwable.(Throwable.java)
> [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at
> java.lang.NullPointerException.(NullPointerException.java:60)
> [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at
> org.apache.ojb.broker.core.PersistenceBrokerImpl.getClassDescriptor(PersistenceBrokerImpl.java)
>
> [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at
> org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java)
>
> [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at
> org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java)
>
> [5/11/06 10:02:15:508 EDT] 24df24df SystemErr R at
> org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:253)
>
> [5/11/06 10:02:15:508 EDT] 24df24df SystemErr R at
> org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:1217)
>
> [5/11/06 10:02:15:508 EDT] 24df24df SystemErr R at
> org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(DelegatingPersistenceBroker.java:338)
>
> [5/11/06 10:02:15:508 EDT] 24df24df SystemErr R at
> org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(DelegatingPersistenceBroker.java:338)
>
> Does anybody have a clue why this might happen very intermittently? Since, it
> is intermittent it is very hard to debug.
>
> -Vamsi
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Only one PB from second database
Hi Armin,
autoCommit set to 1 does not avoid freeze. The fact is that database is only
used to be read, so rollbacks ( by disconnecting) will never be long.
autocommit is however set to 1 now. Thanks for the advice.
I dont' known why it freezes when maxIdle set to -1 and why it does not when
maxIdle is set to 0. But if i well guess, 0 closes usable connections,
that's it ?! So it's not optimized.
Here's my well working conn setup
Regards.
On 5/6/06, Armin Waibel <[EMAIL PROTECTED]> wrote:
Hi Bruno,
Bruno CROS wrote:
> Hi Armin,
>
> In fact, i looked at the DB connections in the DB console. It was a bad
> idea, because connection disappear !! I looked with netstat -a , and i
saw
> several sockets/connections...
>
> Well, i was experiencing some freezes with these connections with a pool
> setup maxActive set to -1. I didn't find any documentation on that
value.
Both ConnectionFactoryPooledImpl and ConnectionFactoryDBCPImpl use
commons-pool to manage connections. There you can find details about the
settings
http://jakarta.apache.org/commons/pool/apidocs/index.html
I would recommend to set maxActive connections at most to the maximal
connections provided by your database server.
> What i known is that, when i put 0 (no limit), it seems there is no more
> freeze.
>
I think there is a typo in documentation. For unlimited connection pool
you have to set -1.
http://jakarta.apache.org/commons/pool/apidocs/org/apache/commons/pool/impl/GenericObjectPool.html
Will fix this till next release.
In your jdbc-connection-descriptor (posted some time ago) you set
useAutoCommit="0". In this case you have to enable autoCommit 'false' in
your jdbc-driver configuration setup, else you will run into rollback
hassle (if autoCommit is 'true' for connections).
regards,
Armin
> Can you ligth up me about that.
>
> Thanks.
>
> Regards.
>
>
>
> On 5/5/06, Armin Waibel <[EMAIL PROTECTED]> wrote:
>>
>> Hi Bruno,
>>
>> Bruno CROS wrote:
>> > Hi,
>> >
>> > I have a strange behaviour about the second database i use. It seems
>> that
>> > using "broker =
>> > PersistenceBrokerFactory.createPersistenceBroker("rushDb");"
>> > always return the same broker/connection.
>> >
>> > My connection pool is setup as it have to keep 2 idle connections
>> > available, and it never occured. Still only one.
>> >
>> > How can i use several connection in this case?
>> >
>> > Note that this database is not not use to update datas. No
transaction
>> are
>> > used on it.
>> >
>>
>> how do you test this behavior? Please setup a test and lookup for two
PB
>> instances at the same time:
>>
>> broker_A = PersistenceBrokerFactory.createPersistenceBroker("rushDb");
>> broker_B = PersistenceBrokerFactory.createPersistenceBroker("rushDb");
>>
>> Are A and B really the same broker instances? If you execute a query on
>> both broker instances (don't close the broker after it) and then lookup
>> the Connection from A and B - are the connections the same?
>>
>> regards,
>> Armin
>>
>> >
>> > Thanks.
>> >
>> >
>> > Here's my connection setup.
>> >
>> >> > jcd-alias="rushDb"
>> > default-connection="false"
>> > platform="MsSQLServer"
>> > jdbc-level="2.0"
>> > driver="com.microsoft.jdbc.sqlserver.SQLServerDriver"
>> > protocol="JDBC"
>> > subprotocol="microsoft:sqlserver"
>> > dbalias="//xxx.x.x.x:1433"
>> > username=""
>> > password=""
>> > batch-mode="true"
>> >useAutoCommit="0"
>> >ignoreAutoCommitExceptions="true"
>> > >
>> >
>> > and pool setup :
>> >
>> >maxActive="5"
>> > maxIdle="-1"
>> >minIdle="2"
>> >maxWait="5000"
>> >whenExhaustedAction="2"
>> >
>> >validationQuery="SELECT CURRENT_TIMESTAMP"
>> >testOnBorrow="true"
>> >testOnReturn="false"
>> >testWhileIdle="true"
>> >timeBetweenEvictionRunsMillis="6"
>> > numTestsPerEvictionRun="2"
>> >minEvictableIdleTimeMillis="180"
>> >removedAbandonned="false"
>> >removeAbandonedTimeout="300"
>> >logAbandoned="true">
>> >
>>
>> -
>> 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: Intermitter error ...
Hi Vamsi, could post more details of the used OJB version and how you are using OJB? Could it be a concurrency issue, is it guaranteed that each thread use it's own PB instance? regards, Armin Vamsi Atluri wrote: Hello all, I am getting this error when I am doing a broker.getCollectionByQuery() very intermittently. The same piece of code works some times and fails some times with this error: [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R java.lang.NullPointerException [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at java.lang.Throwable.(Throwable.java) [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at java.lang.Throwable.(Throwable.java) [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at java.lang.NullPointerException.(NullPointerException.java:60) [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at org.apache.ojb.broker.core.PersistenceBrokerImpl.getClassDescriptor(PersistenceBrokerImpl.java) [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java) [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java) [5/11/06 10:02:15:508 EDT] 24df24df SystemErr R at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:253) [5/11/06 10:02:15:508 EDT] 24df24df SystemErr R at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:1217) [5/11/06 10:02:15:508 EDT] 24df24df SystemErr R at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(DelegatingPersistenceBroker.java:338) [5/11/06 10:02:15:508 EDT] 24df24df SystemErr R at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(DelegatingPersistenceBroker.java:338) Does anybody have a clue why this might happen very intermittently? Since, it is intermittent it is very hard to debug. -Vamsi - 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]
Intermitter error ...
Hello all, I am getting this error when I am doing a broker.getCollectionByQuery() very intermittently. The same piece of code works some times and fails some times with this error: [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R java.lang.NullPointerException [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at java.lang.Throwable.(Throwable.java) [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at java.lang.Throwable.(Throwable.java) [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at java.lang.NullPointerException.(NullPointerException.java:60) [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at org.apache.ojb.broker.core.PersistenceBrokerImpl.getClassDescriptor(PersistenceBrokerImpl.java) [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java) [5/11/06 10:02:15:498 EDT] 24df24df SystemErr R at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java) [5/11/06 10:02:15:508 EDT] 24df24df SystemErr R at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:253) [5/11/06 10:02:15:508 EDT] 24df24df SystemErr R at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:1217) [5/11/06 10:02:15:508 EDT] 24df24df SystemErr R at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(DelegatingPersistenceBroker.java:338) [5/11/06 10:02:15:508 EDT] 24df24df SystemErr R at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(DelegatingPersistenceBroker.java:338) Does anybody have a clue why this might happen very intermittently? Since, it is intermittent it is very hard to debug. -Vamsi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
