objectbridge-developers — public list for developer issues

AW: [OJB-developers] High Low Sequence

[Mahler T. <tho...@it...>]

Hi all,

<snip>
> 
> Another possible problem with the SequenceManagerHighLowImpl 
> (and possibly
> the DefaultImpl as well) is that if several PersistenceBroker 
> acessed the
> same DB there could be race conditions, so we'd need to lock 
> the obj_hl_seq
> table (or at least one row). The question is wether it is 
> possible/good
> style to use the ODMG API (which seems the only way to do 
> locking in OJB)
> within a core class. (I've never actually seen such a race 
> condition and
> haven't run any tests, but I once noticed it and there don't 
> seem to be any
> pre-cautions for this; please correct me if I'm wrong).
> 

I think you are right! currently there is no locking on the ojb_hl_seq.
But I think we can use optimistic locking (which is implemented on the PB
level)
to make sequence numbering thread and multi-user safe.

Thomas

> > Regards Rainer
> 
> regards
> Joachim Sauer
> 
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 

Antwort: Re: [OJB-developers] JUnit Tests & MySQL / global IDs

[<Joa...@tp...>]

> [snip global ids]
>> This is a cool functionality! feel free to contribute it.
>
> I will commit it as soon as I've got a more flexible Configuration
> System working.

Ok, now it's done. It's configurable by setting SequenceManagerGlobalIDs to
true/false. The default-setting (old-style, per-class IDs) will stay,
unless explicitely reconfigured.

It got a little bit of documentation in OJB.properties. I think I'll add
some more documentation in the "true" documentation (as soon as I find the
correct place for it).

>>> The function is not yet configurable (except for setting
>>> globalSequence = true in the constructor and recompiling), as I
>>> don't to wait for the rewrite of BaseConfiguration (which I would
>>> volunteer to do, if no-one has started work on it yet, maybe if
>>> anyone has any design ideas. If not, I'll just do it how I see fit
>>> ;-)
>>
>>
>> I think that no one has started on the refactoring of the
>> Configuration stuff. So you can just give it a try.
>
> OK, I'll try this. My idea is to unite Type-Conversion and
> Default-Values so that an incorrect entry could result in a good
> log-entry and the default value beeing used. something like
> getBoolean("someConfiguration", true) and
> getInteger("someConfiguration", 42) and so on.

Done & checked in. Basically you now have the ability to do a getString,
getBoolean, getInteger with default values. Additionally there's a
getClass-Function, that can even check, wether the specified class
implements/extends the correct Interface/Baseclass. And getStrings() is
just the next-generation parseSeperatedString(). Right now only
PersitenceBrokerFactoryConfiguration and SequenceManagerHighLowImpl use
these functions. I'm pretty sure that some of
PersistenceBrokerFactoryConfigurations getter-methods can be made obsolete
by doing direct get<type>-access in the plugabble classes (like
getSequenceManagerGrabSize()).

regards
Joachim Sauer

RE: [OJB-developers] High Low Sequence

[Bischof, R. <rai...@ed...>]

Jakob,

you got me. I was so sure that there is no reference to the Sequence
instances in the SeqMgr that I did not even have a look at it ;-(

Anyway: 
For those curios: I am using Sun JDK 1.3.1_01 on linux and Tomcat 3.3 in
default configuration without any tuning, OJB is running in single VM mode
and OJB is the only one that has access to the DB. Therefore I always have
increasing IDs, but sometimes the sequence of IDs has holes, e.g.
1,2,6,11,12,...

I can't explain it. Since the SeqMgr always uses it's own Hashtable to look
up the Seq objects the cache settings do not affect - I had the first few
holes again today :-(
All PBs use the SeqMgrFactory and should get the same SeqMgr since the
SeqMgrFactory has a static reference to the SeqMgr. 

Only thing I can imagine right now is that the SeqMgrFactory class is GCed?!
That way new SeqMgr instances may be created.

Regarding race conditions: In case there are multiple PB instances in
different VMs race conditions may occur, also in case the table is directly
modified by another program. 
So the HighLowSeq should not be used in distributed environments or the
issue needs to be fixed somehow.


Any ideas?

rb


-----Original Message-----
From: Joa...@tp... [mailto:Joa...@tp...]
Sent: Donnerstag, 21. Marz 2002 12:10
To: obj...@li...
Subject: [OJB-developers] High Low Sequence



[snip HighLowSequence objects being GCed, resulting in strange ID
sequences]

this doesn't result in incorrect behaviour, but I agree that it wastes
key-space unnecessarily, which is A Bad Thing.

> So there is a need to tell PB to cache instances of HighLowSequence
> forever without giving the GC a chance to collect them.
>
[snip MetaObjectCache solution]
>
> A better solution would be to implement a Set in the HighLowSequence
> where all new instances are added so that these objects are not
> eligible for GC even if the cache reference is only a SoftReference.

hm ... such a Set exists. To be more precise, there is a Hashtable in
SequenceManagerHighLowImpl that holds all HighLowSequence objects that the
SequenceManager has ever used, so they can't be GCed. So I can't see how
this behaviour could possibly happen (of course I don't doubt that you saw
it, I just can't explain why), unless the SequenceManagerHighLowImpl itself
get GCed and re-created (or there are several instances of it).

Maybe you're working with the client/server model. 'Cause then there are
several singlevm PersistenceBrokers on the server and you get to use a new
one each time you issue an command (unless you use and transaction). And
since each of these PersistenceBrokers has its own SequenceManager this
could result in equally confusing id-sequences (or even more confusing
ones, like 1,6,11,2,16,7,3,12,...)

Another possible problem with the SequenceManagerHighLowImpl (and possibly
the DefaultImpl as well) is that if several PersistenceBroker acessed the
same DB there could be race conditions, so we'd need to lock the obj_hl_seq
table (or at least one row). The question is wether it is possible/good
style to use the ODMG API (which seems the only way to do locking in OJB)
within a core class. (I've never actually seen such a race condition and
haven't run any tests, but I once noticed it and there don't seem to be any
pre-cautions for this; please correct me if I'm wrong).

> Regards Rainer

regards
Joachim Sauer


_______________________________________________
Objectbridge-developers mailing list
Obj...@li...
https://lists.sourceforge.net/lists/listinfo/objectbridge-developers

[OJB-developers] ObjectCache and IdentityFactory

[Florian B. <bf...@fl...>]

Hi!

I'm currently investigating how to improve the object cache and how to
create a "factory" for Identity objects.

The object cache already stores identities and objects in a HashMap, but
unfortunately you cannot retrieve the key of a value from a HashMap
reasonably. The idea is now to create a "DoubleHashMap" that maps keys to
values and values to keys in an efficient way using SoftReferences.
Additionally the map could implement things like throwing out gc'd entries
and rehashing in a separate thread, so adding objects to the Map would not
lead to a long processing time if the map decides that rehashing is needed.

Over the last week I've been looking around if there are any implementations
of this concept in the net but found nothing. Then I wrote a little
prototype to get a better feeling for the requirements and complexity of
such a class, but I am not really satisfied with it and it still needs a lot
of work until it is stable enough to be used in OJB.

Now the questions:

- Do you think this approach is valid and is it worth to pursue it

- Does anybody know of an implementation of this concept (I known the
jakarta project has a somewhat related class, but it is a DoubleTreeMap and
we do not need the overhead of sorting the objects).

- Does anybody know of junit tests for Map classes I could use for testing
this implementation

- What else do you think would be needed for such a class

If you have any comments or flames on this, don't hestitate to write a
message, I'd appreciate any comment.

best regards,
Florian

[OJB-developers] High Low Sequence

[<Joa...@tp...>]

[snip HighLowSequence objects being GCed, resulting in strange ID
sequences]

this doesn't result in incorrect behaviour, but I agree that it wastes
key-space unnecessarily, which is A Bad Thing.

> So there is a need to tell PB to cache instances of HighLowSequence
> forever without giving the GC a chance to collect them.
>
[snip MetaObjectCache solution]
>
> A better solution would be to implement a Set in the HighLowSequence
> where all new instances are added so that these objects are not
> eligible for GC even if the cache reference is only a SoftReference.

hm ... such a Set exists. To be more precise, there is a Hashtable in
SequenceManagerHighLowImpl that holds all HighLowSequence objects that the
SequenceManager has ever used, so they can't be GCed. So I can't see how
this behaviour could possibly happen (of course I don't doubt that you saw
it, I just can't explain why), unless the SequenceManagerHighLowImpl itself
get GCed and re-created (or there are several instances of it).

Maybe you're working with the client/server model. 'Cause then there are
several singlevm PersistenceBrokers on the server and you get to use a new
one each time you issue an command (unless you use and transaction). And
since each of these PersistenceBrokers has its own SequenceManager this
could result in equally confusing id-sequences (or even more confusing
ones, like 1,6,11,2,16,7,3,12,...)

Another possible problem with the SequenceManagerHighLowImpl (and possibly
the DefaultImpl as well) is that if several PersistenceBroker acessed the
same DB there could be race conditions, so we'd need to lock the obj_hl_seq
table (or at least one row). The question is wether it is possible/good
style to use the ODMG API (which seems the only way to do locking in OJB)
within a core class. (I've never actually seen such a race condition and
haven't run any tests, but I once noticed it and there don't seem to be any
pre-cautions for this; please correct me if I'm wrong).

> Regards Rainer

regards
Joachim Sauer

Re: [OJB-developers] JUnit Tests & MySQL / global IDs

[<Joa...@tp...>]

hy all,

[snip MySQL and testEscaping with trailing spaces]
>
> I agree. This test must only check proper treating of quotes.
>
[snip]
>
> Mh, I don't think that we really need this TestCase. It's also of
> little use as we know that it is doomed to fail with MySql.

Then I'll change the test to leave out the trailing spaces.

[snip global ids]
> This is a cool functionality! feel free to contribute it.

I will commit it as soon as I've got a more flexible Configuration System
working.

>> The function is not yet configurable (except for setting
>> globalSequence = true in the constructor and recompiling), as I
>> don't to wait for the rewrite of BaseConfiguration (which I would
>> volunteer to do, if no-one has started work on it yet, maybe if
>> anyone has any design ideas. If not, I'll just do it how I see fit
>> ;-)
>
>
> I think that no one has started on the refactoring of the
> Configuration stuff. So you can just give it a try.

OK, I'll try this. My idea is to unite Type-Conversion and Default-Values
so that an incorrect entry could result in a good log-entry and the default
value beeing used. something like getBoolean("someConfiguration", true) and
getInteger("someConfiguration", 42) and so on.

[snip cvs checking rules]
>
> 3. If you are checking in code that implements new features, please
> also provide JUnit Testcases that validate the new functionality. If
> the new features are visible to the end-user please also add (or
> modify) documentation.

do we also need JUnit Tests for such configureable features as the global
High/Low ID Generator? The Problem here is the same as with JUnit tests for
the C/S-mode. We'd need to  modify OJB.properties to test these features.
We either make a general system for changeing specific configuration
entries for specific tests or rewrite the build.xml to re-run the tests
with several alternate configurations. Does Sourceforge allow running
automated regression tests on their system? This way we'd be able to run
regression tests against several databases every day. If sourceforge
doesn't allow such things, we could do this on our internal system (we have
similar regression tests, along with auto-generated documentation for our
internal project) as soon as our server is back to live (right now he is in
a rather bad condition).

[snip]
> 5. We currently don't have a proper change management system. But
> there is a excel file (todo.xls) in the base dir of the OJB-1-0
> project. Please add your changes to this file. This file is used to
> assemble the change log for new releases. Thus it is important to
> register all changes here ! (If you have an idea how to provide a
> better change management please contact me.)

I suggest we don't use and excel file, for several reasons, some of which
are just my personal taste and might therefore not be inportant:

- many people don't run Windows & those who do might not have Excel
(fortunately I (have to) use Windows and work and do have Excel installed).
- cvs can't give you a meaningfull diff of any Office document.
- security implications (cut & paste from/to office documents might copy
more than is visible)
- i don't like Excel ;-)

a simple text-format TODO might be an alternative. Granted, handling this
would be a bit more complicated, but at least everyone can do it. Another
idea for a changelog might be something along the lines of cvs2pl (to be
found at http://www.red-bean.com/cvs2cl/), I just recently found it and
haven't tried it, but it looks interesting.

(I'll just update my changes there nevertheless, until we find an
alternative)

>> btw, anyone got a problem, when I check in a .cvsignore file into
>> CVS that contains *.class?
>
> should be no problem!

I should read the cvs-documentation before doing such things ;-) .cvsignore
only works in the current directory, so I now use "build" and "dist"
instead of "*.class".

> cu,
>
> Thomas

regards
Joachim Sauer

[OJB-developers] High Low Sequence

[Bischof, R. <rai...@ed...>]

All,
 
I just discovered some strange behaviour  for the SequenceManagerHighLowImpl
:
Instances of HighLowSequence are just normal objects, so they are cached.
When the system has worked under high load for some time (i.e. used some
memory) the Sequence objects may be removed from the default cache because
the GC collects them.
So they need to be reloaded the next time an identity is generated, and upon
reload they are inititlaized with the latest state from the DB. This creates
the Sequence objects with a new High value and thus reserves the next set of
IDs  although the last one was not fully used. 
This may cause some holes in the sequence, so when you have a grabsize of 5
you may have the following sequence: 1,6,11,16, 21,...
The strange looking thing is that you may have chaotic sequences like:
1,2,3,4,6,11,16,21,22,26,... 
 
So there is a need to tell PB to cache instances of HighLowSequence forever
without giving the GC a chance to collect them.
 
There is a MetaObjectCacheImpl and a PermanentObjectCacheImpl which can be
used together to solve this. Just configure PB to use the
MetaObjectCacheImpl instead of the default one and initialize the cache with
the following code:
 
            ( ( MetaObjectCacheImpl ) ObjectCacheFactory.getObjectCache()
).setClassCache( HighLowSequence.class, new PermanentObjectCacheImpl() );

Now you are tied to the given MetaObjectCache, though :-(
 
A better solution would be to implement a Set in the HighLowSequence where
all new instances are added so that these objects are not eligible for GC
even if the cache reference is only a SoftReference.
 
Regards
Rainer
 

Rainer Bischof
EDS - Electronic Data Systems
European Automotive Solution Center - Distributed Solutions
Email: rai...@ed... <mailto:rai...@ed...> 
Tel: +49 (0) 6142 / 802975
Dial8: 8-969-2975 

 

Re: [OJB-developers] JUnit Tests & MySQL / global IDs

[Thomas M. <tho...@ho...>]

Hi Joachim,

Joa...@tp... wrote:

> Hy,
> 
> I've got several questions. First of all I still got the trouble with MySQL
> failing a Broker Test (PersistenceBrokerTest.testEscaping()) and it doesn't
> seem that this will be resolved, unless we change the Test. MySQL doesn't
> have a problem with the escaping but with trailing spaces (the get striped
> in the database). I suggest that the trailing spaces in the escaping Test
> are removed.


I agree. This test must only check proper treating of quotes.

> The questions is whether we want to do the
> trailing-spaces-Test as well (which would again result in a Failure with
> MySQL, but at least it would be more precise). I'd be willing to make this
> Change, if no-one objects.


Mh, I don't think that we really need this TestCase. It's also of little 
use as we know that it is doomed to fail with MySql.


> 
> Then there is my newly created Option for SequenceManagerHighLowImpl, which
> allows for OID that are unique over all classes (to be exact they are
> unique over all classes that use the same name for their ID-field. This was
> necessary to allow the JUnit tests to pass and will not be a problem,
> 'cause when you use this function you're likely to use an oid-field (or
> something) for all classes). The implementation cannot really handle Data
> being inserted into the DB without using it for acquiring the IDs with this
> function. So it is quite useless for accessing legacy data, but for our
> product it is just fine (we won't have any DB-access without OJB). 


This is a cool functionality! feel free to contribute it.

> The
> function is not yet configurable (except for setting globalSequence = true
> in the constructor and recompiling), as I don't to wait for the rewrite of
> BaseConfiguration (which I would volunteer to do, if no-one has started
> work on it yet, maybe if anyone has any design ideas. If not, I'll just do
> it how I see fit ;-)


I think that no one has started on the refactoring of the Configuration 
stuff. So you can just give it a try.


> 
> Well, basically most of my questions boil down to one point: are there any
> cvs-checkin rules that should be obeyed? Not breaking the JUnit tests seems
> to be an obvious test.


Yes, this is an essential point !

> Any others? How about new functionality, should it
> be discussed on this list before check in? Bug fixes?
> 


We have not yet any fixed set of rules yet. I'm planning to provide a 
little document on this topic. For the time being here are some guidelines:

1. Before checking in code, please assure that all things compile and 
that all JUnit tests pass successfully.

2. Before checking in code please check for conflicts with checkins of 
others. IDEs like eclipse will help you to merge things together.
Before commiting merged files please again check 1.)

3. If you are checking in code that implements new features, please also 
provide JUnit Testcases that validate the new functionality.
If the new features are visible to the end-user please also add (or 
modify) documentation.

  4. Before starting major refactorings or adding new features please 
make a proposal to the developer list for discussion. If there are no 
objections: feel free to start.

5. We currently don't have a proper change management system. But there 
is a excel file (todo.xls) in the base dir of the OJB-1-0 project. 
Please add your changes to this file.
This file is used to assemble the change log for new releases. Thus it 
is important to register all changes here !
(If you have an idea how to provide a better change management please 
contact me.)


> btw, anyone got a problem, when I check in a .cvsignore file into CVS that
> contains *.class?


should be no problem!

cu,

Thomas


> 
> regards
> Joachim Sauer
> 
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 
> 
> 
> 

Re: [OJB-developers] Why repository.xml has to be in app CLASSPATH

[Thomas M. <tho...@ho...>]

Hi Leandro,

Please refer to the attached document describing the necessary steps to 
deploy OJB in Web Apps.

OJB.properties and repository.xml *must* be in the classpath because OJB 
uses classloader based rsource lookup.
This is the official way to access files within J2EE environments.

HTH,

Thomas

Leandro Rodrigo Saad Cruz wrote:

> Hi all, I'm trying to setup OJB to work with an WEB-APP and I am having
> some problems because repository.xml has to be in $CLASSPATH.
> Is there any reason for this ?
> Is this a feature ?
> 
> 

[OJB-developers] Why repository.xml has to be in app CLASSPATH

[Leandro R. S. C. <le...@ib...>]

Hi all, I'm trying to setup OJB to work with an WEB-APP and I am having
some problems because repository.xml has to be in $CLASSPATH.
Is there any reason for this ?
Is this a feature ?

-- 
Leandro Rodrigo Saad Cruz
IT - Inter Business Tecnologia e Servicos (IB)
http://www.ibnetwork.com.br

[OJB-developers] JUnit Tests & MySQL / global IDs

[<Joa...@tp...>]

Hy,

I've got several questions. First of all I still got the trouble with MySQL
failing a Broker Test (PersistenceBrokerTest.testEscaping()) and it doesn't
seem that this will be resolved, unless we change the Test. MySQL doesn't
have a problem with the escaping but with trailing spaces (the get striped
in the database). I suggest that the trailing spaces in the escaping Test
are removed. The questions is whether we want to do the
trailing-spaces-Test as well (which would again result in a Failure with
MySQL, but at least it would be more precise). I'd be willing to make this
Change, if no-one objects.

Then there is my newly created Option for SequenceManagerHighLowImpl, which
allows for OID that are unique over all classes (to be exact they are
unique over all classes that use the same name for their ID-field. This was
necessary to allow the JUnit tests to pass and will not be a problem,
'cause when you use this function you're likely to use an oid-field (or
something) for all classes). The implementation cannot really handle Data
being inserted into the DB without using it for acquiring the IDs with this
function. So it is quite useless for accessing legacy data, but for our
product it is just fine (we won't have any DB-access without OJB). The
function is not yet configurable (except for setting globalSequence = true
in the constructor and recompiling), as I don't to wait for the rewrite of
BaseConfiguration (which I would volunteer to do, if no-one has started
work on it yet, maybe if anyone has any design ideas. If not, I'll just do
it how I see fit ;-)

Well, basically most of my questions boil down to one point: are there any
cvs-checkin rules that should be obeyed? Not breaking the JUnit tests seems
to be an obvious test. Any others? How about new functionality, should it
be discussed on this list before check in? Bug fixes?

btw, anyone got a problem, when I check in a .cvsignore file into CVS that
contains *.class?

regards
Joachim Sauer

Re: [OJB-developers] Why use PersistenceBrokerImpl instead of PersistenceBroker in the constructor for StatementManager/connectionManager?

[Thomas M. <tho...@ho...>]

Hi John,

John Wang wrote:

 > As I want to override the functins of PersistenceBrokerImpl to expose
 > more functions, I am wondering that in the constructor for:
 >
 > StatementManager.java
 >
 > ConnectionFactoryDefaultImpl.java
 >
 > ConnectionManager.java
 >
 > SequenceManager.java
 >
 > ...
 >
 > They all use the PersistenceBrokerImpl as a parameter in the
 > constructor, instead of using PersistenceBroker. I am wondering is there
 > specific reason to use impl instead of interface?
 >


I'm not sure if it is always necessary to pass PBImpl instead PB
objects. But there are at least several places where it's obligatory to
pass PBImpl.
PBImpl provide several things not present in PB interface.

BUT: if you derive modified Brokers that extend PBImpl there will be no
problems.

BTW:
What additional functionality do you want to expose? Maybe its useful
for others too?

cu,

Thomas


 >
 >
 > Best regards,
 >
 > John W
 >
 >
 >

[OJB-developers] Re: JBOSS/OJB code

[Thomas M. <tho...@ho...>]

Hi Jesper,

Jesper Ladegaard wrote:

  > Hi again Thomas
  >
<snip>
  >
  > This is where JCA comes into the picture. The EJB server will
  > attach/detach tx-context to connection/broker resource on demand. It's
  > important there's no fixed 1-1 relationship between transaction and
  > broker. For example, it must be possible for any broker in the pool to
  > commit any active transaction. The transaction manager of the EJB
  > server only guarantees that only one transaction is active on a single
  > connection at any time.
  >

I see! Now the overall picture becomes much clearer to me.

  >
  >> Armin uses a JNDI lookup to obtain a TransactionManager instance.
  >> But we are not sure if there is an "official" way to do this.
  >>
  >
  > It's possible to obtain the TransactionManager and register a
  > javax.transaction.Synchronization with the current
  > transaction. However, this is mostly used for non-XA-aware programs
  > (i.e. client/user code) that are interrested in a callback when the
  > transaction completes.
  >
  > The official way is to enlist a XAResource with the transaction.
  > However, supporting the JCA connection contract and the connection
  > manager of the application server will take care of enlisting the
  > XAResouce for us, which is the official way of doing this in J2EE 1.3.
  >

That was the answer I was looking for!
Do you know if this mechanism is implemented in JBOSS (2.4.4 or 3.0) ?


  >
  >> If there is no standardized way for this it will be difficult to
  >> integrate OJB into different EJB Containers.
  >>
  >>
  >
  > Exactly! And this is the very reason we must support JCA, which was
  > created to solve this exact problem, plus some others also.
  >

OK !

  > [snip...]
  >
  >
  >> I think we can learn a lot from the stuff the CASTOR and Tyrex
  >> developers did in this area.
  >>
  >
  > What did they do?
  >
  > I've looked at CASTOR's code once, however it was a long time ago.
  > Their code was not nice then, but I don't know how their transaction
  > stuff works today?
  >

I don't like most of their code too. But they provide JTA and XA
implementations.
They also provide full integration with the Tyrex TransactionManager.

AFAIK that's why CASTOR integrates smoothly with JBOSS.

<snip>

  > IMO, the biggest task is for us to create a robust design for
  > integrating standard-based transaction support into OJB.
  >
  > For example, some people uses the "OBJ mode" and don't care about
  > ODMG. Others (like me) want's to use ODMG. The tx stuff should
  > intergrate and work the same for both methods.

I agree !
I would even prefer to have JTA/XA/JCA stuff only on the ODMG or JDO
level and not for the PersistenceBroker kernel.
But there are a lot of people that use the PersistenceBroker API only.
Thus they also want to have JTA/XA/JCA.

  > I mean, there seems to be a lot of confusion here. For example both
  > JBOSS integrations you've send me only works in OJB mode.
  >

I think it's OK to start with the PB to get some hands on experience.

cu,

Thomas

  > Regards Jesper
  >
  >
  >
  >
  >

[OJB-developers] Why use PersistenceBrokerImpl instead of PersistenceBroker in the constructor for StatementManager/connectionManager?

[John W. <hw...@re...>]

As I want to override the functins of PersistenceBrokerImpl to expose =
more functions, I am wondering that in the constructor for:
StatementManager.java
ConnectionFactoryDefaultImpl.java
ConnectionManager.java
SequenceManager.java
...
They all use the PersistenceBrokerImpl as a parameter in the =
constructor, instead of using PersistenceBroker. I am wondering is there =
specific reason to use impl instead of interface?

Best regards,
John W

[OJB-developers] Configuration & SequenceManager

[<Joa...@tp...>]

Hy,

I'm currently looking at writing a custom SequenceManager, 'cause we want
to keep our OID-System (OIDs unique over all tables, special prefix per
Client (not used in buisness logic, just for ease of debuging) and a
timestamp from the creation of the object). For this I wanted to extend
SequenceManagerHighLowImpl to allow the first part (unique OIDs) with an
configuration option (The other stuff would go in a seperate class, as I
don't think it is useable for anyone else). Unfortunately it seems there is
no generic configuration ability for plugable classes (such as
SequenceManager). Is it really the case that whenever I want to use a
plugable class that can have some options I have to modify
PersistenceBrokerConfiguration as well? A simple API for such plugable
Classes to allow reading some Configuration from the OJB.properties would
be good (exposing the Properties-object would be sufficient IMHO).

regards
Joachim Sauer

[OJB-developers] WG: [Fwd: Re: Re: JBOSS/OJB code]

[Mahler T. <tho...@it...>]

> -----Urspr=FCngliche Nachricht-----
> Von: Thomas Mahler [mailto:tho...@ho...]
> Gesendet: Dienstag, 19. M=E4rz 2002 07:07
> An: tom
> Betreff: [Fwd: Re: Re: JBOSS/OJB code]
>=20
>=20
>=20
>=20
> -------- Original Message --------
> Subject: Re: Re: JBOSS/OJB code
> Date: Mon, Mar 18 2002 23:37:00 GMT+0100
> From: jl...@pi... (Jesper Ladegaard)
> To: Thomas Mahler <tho...@ho...>
>=20
> Hi again Thomas
>=20
> [snip]
>  > There is one issue I found: The J2EE spec tells
>  > how a client can obtain a user Transaction (by
>  > EJBContext.getUserTransaction()).
>  >
>  > But I did not find any specification how a "JTA
>  > provider" like OJB can obtain a TransactionManager
>  > instance to obtain external transactions.
>  >
>  > IMO we will need this in the PBF to associate
>  > new PB instances with external transactions.
>=20
> This is where JCA comes into the picture. The EJB server will=20
> attach/detach tx-context to connection/broker resource on=20
> demand. It's=20
> important there's no fixed 1-1 relationship between transaction and=20
> broker. For example, it must be possible for any broker in=20
> the pool to=20
> commit any active transaction. The transaction manager of the=20
> EJB server=20
> only guarantees that only one transaction is active on a single=20
> connection at any time.
>=20
>  >
>  > Armin uses a JNDI lookup to obtain a TransactionManager
>  > instance. But we are not sure if there is an "official"
>  > way to do this.
>=20
> It's possible to obtain the TransactionManager and
> register a javax.transaction.Synchronization with the current=20
> transaction. However, this is mostly used for non-XA-aware programs=20
> (i.e. client/user code) that are interrested in a callback when the=20
> transaction completes.
>=20
> The official way is to enlist a XAResource with the transaction.=20
> However, supporting the JCA connection contract and the connection=20
> manager of the application server will take care of enlisting the=20
> XAResouce for us, which is the official way of doing this in J2EE =
1.3.
>=20
>  > If there is no standardized way for this it will be
>  > difficult to integrate OJB into different EJB
>  > Containers.
>  >
>=20
> Exactly! And this is the very reason we must support JCA, which was=20
> created to solve this exact problem, plus some others also.
>=20
> [snip...]
>=20
>  > I think we can learn a lot from the stuff the
>  > CASTOR and Tyrex developers did in this area.
>=20
> What did they do?
>=20
> I've looked at CASTOR's code once, however it was a long time=20
> ago. Their=20
> code was not nice then, but I don't know how their transaction stuff=20
> works today?
>=20
>  > Providing JUnit test cases is definitely a must.
>  > But it will also very difficult to support the
>  > large variety of scenarios you mention.
>=20
> yes, and I don't think we'll get everything right the first time.=20
> However, from looking at JBoss code and their JDBC and JMS adapter, I =

> can see they don't support many of the senarios either.
>=20
>  >
>  > You will need a comple test lab to do this job properly !
>=20
> I hope not :-)
>=20
>  > I found that it is even difficult to provide support
>  > for the most popular RDBMS.
>  > I'm running Junit tests against HSQLDB, MS-Access,
>  > Oracle and DB2.
>  > But I don't have an Informix DB and I don't have
>  > any MySQL Know-How.
>  > You'll definitely need a team of test engineers,
>  > a server farm and several licences for RDBMS
>  > products to do this job professionally.
>=20
> I can imagine that.
>=20
>=20
>  > I think we'll need a lot of creativity to setup
>  > testscenarios that give us feedback on the quality
>  > of the JTA/JCA Integration!
>=20
> Really!
> I don't think this is such a big problem.
>=20
> IMO, the biggest task is for us to create a robust design for=20
> integrating standard-based transaction support into OJB.
>=20
> For example, some people uses the "OBJ mode" and don't care=20
> about ODMG.=20
> Others (like me) want's to use ODMG. The tx stuff should=20
> intergrate and=20
> work the same for both methods. I mean, there seems to be a lot of=20
> confusion here. For example both JBOSS integrations you've=20
> send me only=20
> works in OJB mode.
>=20
> Regards
> Jesper
>=20
>=20
>=20
>=20
>=20

Re: [OJB-developers] query based on example object

[Jakob B. <jbr...@ho...>]

hi thomas,

the solution in it's current state is quite simple: it only uses non null
instvars to produce EqualsToCriteria.
problems arise with primitives as the can't be null.
i thought of some kind of include/exclude lists, but it's not implemented
yet.

jakob

----- Original Message -----
From: "Thomas Mahler" <tho...@ho...>
To: "Jakob Braeuchi" <jbr...@ho...>
Cc: <obj...@li...>
Sent: Monday, March 18, 2002 9:12 PM
Subject: Re: [OJB-developers] query based on example object


> Hi Jakob,
>
> This looks like a useful feature!
> When I first implemented QueryByExample (QBE) I did only implement a
> primary key based version.
>
> I did not implement a generic solution as I found some difficulties.
> Imagine, you don't call example.setTest(11);
>
> The respective attribute will then be == 0;
>
> How can we distinguish such an "un-willed" zero from a "willed"
> example.setTest(0);
>
>
> There are similar problems for null String attributes.
>
> Did you address these problems in your solution?
>
> cu,
>
> Thomas
>
>
>
>
> Jakob Braeuchi wrote:
>
> > hi ,
> >
> > i just comitted a small feature to the cvs: building a QueryByCriteria
based
> > on an example object.
> >
> > Person example = new Person();
> > Query query;
> >
> > example.setBoss(false);
> > example.setTest(11);
> > example.setName("Br%");
> > query = new QueryByCriteria(example);
> >
> > this will build a QueryByCriteria with the following criteria:
> > boss = false AND test=11 AND name like "Br%"
> >
> > i didn't want to change the class QueryByExample nor the method
> > newQuery(Object obj) of class QueryFactory because
> > QueryByExample uses the Identity to retrieve Objects. Actually
> > QueryByExample could be renamed QueryByIdentity...
> >
> > jakob
> >
> > _______________________________________________
> > Objectbridge-developers mailing list
> > Obj...@li...
> > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> >
> >
> >
> >
>
>
>

[OJB-developers] Re: JBOSS/OJB code

[Thomas M. <tho...@ho...>]

Hi Jesper,

Jesper Ladegaard wrote:

<snip>
> 
> OK. Please tell, if you run into some TX issues you think are important or
> something to be aware of.


There is one issue I found: The J2EE spec tells how a client can obtain 
a user Transaction (by EJBContext.getUserTransaction()).

But I did not find any specification how a "JTA provider" like OJB can 
obtain a TransactionManager instance to obtain external transactions.

IMO we will need this in the PBF to associate new PB instances with 
external transactions.

Armin uses a JNDI lookup to obtain a TransactionManager instance. But we 
are not sure if there is an "official" way to do this.
If there is no standardized way for this it will be difficult to 
integrate OJB into different EJB Containers.


> 
> There are properly a couple of devils hiding in the details. I've never
> created a JCA adapter before, but
> have been working with JTS/JTA a bit. However, most of my knowledge comes
> from have been working with CORBA transaction server (CosTransaction) a lot.
> 
> When we get some JCA/JTA up running, it will properly be a good idea to
> create some tests for it (i.e. by using JUnit test from a session bean).
> Also if we're going to use different kind of transaction implementation, the
> tests would be very nice. Depending on how intelligent the container,
> transaction, and connection manager are, there may be issues such as
> transaction interleaving from multiple thread contexts, resource sharing,
> thread-safety on XAResource, and so on. However, if the OBJ OTM is
> structured ok, then this should be no problem (hopefully).
> 


I think we can learn a lot from the stuff the CASTOR and Tyrex 
developers did in this area.

Providing JUnit test cases is definitely a must. But it will also very 
difficult to support the large variety of scenarios you mention.

You will need a comple test lab to do this job properly !

I found that it is even difficult to provide support for the most 
popular RDBMS.
I'm running Junit tests against HSQLDB, MS-Access, Oracle and DB2.
But I don't have an Informix DB and I don't have any MySQL Know-How.
You'll definitely need a team of test engineers, a server farm and 
several licences for RDBMS products to do this job professionally.

I think we'll need a lot of creativity to setup testscenarios that give 
us feedback on the quality of the JTA/JCA Integration!

cu,

Thomas


> Regards
> Jesper
> 
> 
> 
> 
> 

Re: [OJB-developers] query based on example object

[Thomas M. <tho...@ho...>]

Hi Jakob,

This looks like a useful feature!
When I first implemented QueryByExample (QBE) I did only implement a 
primary key based version.

I did not implement a generic solution as I found some difficulties.
Imagine, you don't call example.setTest(11);

The respective attribute will then be == 0;

How can we distinguish such an "un-willed" zero from a "willed"
example.setTest(0);


There are similar problems for null String attributes.

Did you address these problems in your solution?

cu,

Thomas




Jakob Braeuchi wrote:

> hi ,
> 
> i just comitted a small feature to the cvs: building a QueryByCriteria based
> on an example object.
> 
> Person example = new Person();
> Query query;
> 
> example.setBoss(false);
> example.setTest(11);
> example.setName("Br%");
> query = new QueryByCriteria(example);
> 
> this will build a QueryByCriteria with the following criteria:
> boss = false AND test=11 AND name like "Br%"
> 
> i didn't want to change the class QueryByExample nor the method
> newQuery(Object obj) of class QueryFactory because
> QueryByExample uses the Identity to retrieve Objects. Actually
> QueryByExample could be renamed QueryByIdentity...
> 
> jakob
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 
> 
> 
> 

[OJB-developers] query based on example object

[Jakob B. <jbr...@ho...>]

hi ,

i just comitted a small feature to the cvs: building a QueryByCriteria based
on an example object.

Person example = new Person();
Query query;

example.setBoss(false);
example.setTest(11);
example.setName("Br%");
query = new QueryByCriteria(example);

this will build a QueryByCriteria with the following criteria:
boss = false AND test=11 AND name like "Br%"

i didn't want to change the class QueryByExample nor the method
newQuery(Object obj) of class QueryFactory because
QueryByExample uses the Identity to retrieve Objects. Actually
QueryByExample could be renamed QueryByIdentity...

jakob

[OJB-developers] Classcast exception: java.lang.Doulee Error while testing run_broker_example on Oracle 8i

[hwang <hw...@re...>]

When I test the build run_broker_example on the oracle database, I got the 
exception:
    [junit] java.lang.ClassCastException: java.lang.Double
    [junit]     at 
oracle.jdbc.driver.OraclePreparedStatement.setObject(OraclePr
eparedStatement.java:1980)
    [junit]     at 
oracle.jdbc.driver.OraclePreparedStatement.setObject(OraclePr
eparedStatement.java:2052)
    [junit]     at 
ojb.broker.accesslayer.StatementManager.bindInsert(StatementM
anager.java:293)
    [junit]     at 
ojb.broker.accesslayer.JdbcAccess.executeInsert(JdbcAccess.ja
va:151)
    [junit]     at 
ojb.broker.singlevm.PersistenceBrokerImpl.store(PersistenceBr
okerImpl.java:1347)
    [junit]     at 
ojb.broker.singlevm.PersistenceBrokerImpl.store(PersistenceBr
okerImpl.java:313)
    [junit]     at 
test.ojb.broker.BrokerExamples.testShallowAndDeepRetrieval(Br
okerExamples.java:229)

Has anybody has such problem before?
Thanx,
John W

[OJB-developers] deploying OJB

[Thomas M. <tho...@ho...>]

Hi all,

In the last weeks there have been several questions "how to deploy OJB 
in my environment".

I started a document answering these questions. (see it attached). I'll 
make this part of the OJB docs.

Feel free to comment, provide improvements or corrections.

thanks,

Thomas

Re: [OJB-developers] About connection pool and preparedstatement cache]

[Thomas M. <tho...@ho...>]

Hi John,

John Wang wrote:

> Well, sorry for my midunderstanding before, I think the connectionmanager
> belongs the persistencebroker, so if several users comes in, they use the
> different persistencebroker, thus use different connectionmanager and jdbc
> connection.


Exactly! That was the point I tried to explain in my previous mails.
Users usually won't work directly with Connections.


> How to specify a type of JDBC connection for a class descriptor in
> configuration file? Usually it used the "default" one, right?
> thankx,


If you have a look at the repository.dtd you will see that the 
Repository must contain a default JdbcConnectionDescriptor right at the 
beginning of the repository.
But the definition for the ClassDescriptor element also contains an 
optional JdbcConnectionDescriptor element. Thus it is possible to place 
a JdbcConnectionDescriptor at the beginning of a ClassDescriptor like 
follows:


<ClassDescriptor id="1">
   <JdbcConnectionDescriptor id="default">
     <dbms.name>Hsqldb</dbms.name>
     <driver.name>org.hsqldb.jdbcDriver</driver.name>
     <url.protocol>jdbc</url.protocol>
     <url.subprotocol>hsqldb</url.subprotocol>
     <url.dbalias>../OJB</url.dbalias>
     <user.name>sa</user.name>
     <user.passwd></user.passwd>
   </JdbcConnectionDescriptor>

   <class.name>test.ojb.broker.Article</class.name>
   <class.proxy>dynamic</class.proxy>
   <class.extent>test.ojb.broker.BookArticle</class.extent>
   <class.extent>test.ojb.broker.CdArticle</class.extent>
   <table.name>Artikel</table.name>
   ...
</ClassDescriptor>


HTH,

Thomas





> John W
> 
> ----- Original Message -----
> From: "John Wang" <hw...@re...>
> To: <obj...@li...>
> Sent: Thursday, March 14, 2002 11:52 AM
> Subject: Re: [OJB-developers] About connection pool and preparedstatement
> cache]
> 
> 
> 
>>Thomas:
>>   When I read the source code, I am still confused about the relationship
>>about  the management of jdbc connections. It seems like that the
>>
> connection
> 
>>is allocated based on the classdescriptor, though I am not sure how to
>>dedicate a JdbcConnectionDescriptor to a classdescriptor, but suppose it
>>
> is
> 
>>possible, I am still confused about the way jdbc connection is used.
>>   Usually in web application, several users may access the same classes
>>
> at
> 
>>the same time, say updating a different article, and they should be
>>
> handled
> 
>>by different jdbc connection. But according to
>>ConnectionManager.getConnectionForClassDescriptor() method, it always
>>
> return
> 
>>the same connection for a single type of classes. So if two users are
>>accessing the article class at the same time, they will share the same
>>connection. That's what I am worried about.
>>   Hope you can explain a litter bit more,
>>   Best regards,
>>John W
>>
>>----- Original Message -----
>>From: "Thomas Mahler" <tho...@ho...>
>>To: "John Wang" <hw...@re...>
>>Sent: Monday, March 11, 2002 10:38 PM
>>Subject: Re: [OJB-developers] About connection pool and preparedstatement
>>cache]
>>
>>
>>
>>>Hi again John,
>>>
>>>John Wang wrote:
>>>
>>>
>>>>Thanks for your response.
>>>>
>>>>
>>>>
>>>>>. If you are
>>>>>running a servlet engine and your machine is powerful enough the best
>>>>>thing is to run OJB within the same VM as the servlet engine.
>>>>>
>>>>>
>>>>I agree with you. I am just wondering how to support multiple
>>>>
> concurrent
> 
>>>>requests in the servlet engine. Say user A's request comes in, the
>>>>
>>servlet
>>
>>>>will use the PersistenceBrokerImpl and its connection, before the
>>>>
>>servlet
>>
>>>>finishes this request and commit his changes, user B's request comes
>>>>
> in,
> 
>>>>should he create a new PersistenceBrokerImpl and a new connection? I
>>>>
>>assume
>>
>>>>that he can't use the same PersistenceBrokerImpl and the connection
>>>>
> with
> 
>>>>User A, because user A hasn't committed the changes yet.
>>>>
>>>
>>>Yes simply obtain a new PersistenceBroker to perform transactions in
>>>parallel. Use PersistenceBrokerFactory for this.
>>>It is important to release broker instances after use with
>>>PersistenceBrokerFactory.releaseInstance(broker).
>>>
>>>Of course it may also be a valid approach to serialize all user
>>>transactions. That is use just a single broker instance. Thus your app
>>>must wait for proccessing B until A's  transaction is commited.
>>>
>>>hth,
>>>
>>>Thomas
>>>
>>>
>>>
>>>>Hope it is clear,
>>>>thanks again,
>>>>John W
>>>>
>>>>
>>>>----- Original Message -----
>>>>From: "Thomas Mahler" <tho...@ho...>
>>>>To: "John Wang" <hw...@re...>
>>>>Cc: <obj...@li...>
>>>>Sent: Monday, March 11, 2002 11:35 AM
>>>>Subject: Re: [OJB-developers] About connection pool and
>>>>
>>preparedstatement
>>
>>>>cache]
>>>>
>>>>
>>>>
>>>>
>>>>>Hi again John
>>>>>
>>>>>John Wang wrote:
>>>>>
>>>>>
>>>>>
>>>>>>I am thinking that in a web application development, usually we use
>>>>>>
> a
> 
>>>>>>connection pool, and get a connection from there.
>>>>>>
>>>>>>
>>>>>OK
>>>>>
>>>>>
>>>>>
>>>>>>So in the app server, say
>>>>>>tomcat, need to maintain a pool of connections(I guess we should use
>>>>>>PersistenceBrokerImpl for OJB), and use app server's load balancer
>>>>>>
> and
> 
>>>>>>JOB's
>>>>>>distributed cache to improve the performance and workload. I am very
>>>>>>concerned about the performance of OJB's C/S mode and other network
>>>>>>
>>>>>>
>>>>calle
>>>>
>>>>
>>>>>>mechanisms(like ejb), I am thinking that this may be a better
>>>>>>
>>approach.
>>
>>>>Do
>>>>
>>>>
>>>>>>you agree with me?
>>>>>>
>>>>>>
>>>>>I'm not sure if I got you right. But I give it a try:
>>>>>The OJB way of working with PreparedStatements is to cache them for
>>>>>maximum performance. To keep a PreparedStatement hot the underlying
>>>>>
> Jdbc
> 
>>>>>Connection must be active.
>>>>>Thus if you return the connection object used by the OJB broker to the
>>>>>app servers pool OJBs caching of PreparedStatements would be
>>>>>
>>superfluous.
>>
>>>>>Before re-using a PreparedStatement OJB checks if the connection is
>>>>>still alive.
>>>>>Thus it is totally safe to release the Connection object to the app
>>>>>servers pool.
>>>>>
>>>>>Feel free to do this! But imho it will have a negative performance
>>>>>
>>impact.
>>
>>>>>I don't understand why you bring in the OJB C/S mode here. If you are
>>>>>running a servlet engine and your machine is powerful enough the best
>>>>>thing is to run OJB within the same VM as the servlet engine.
>>>>>
>>>>>If you are forced to scale, that is run Servlet Engine and OJB on
>>>>>multiple machines you must use the OJB C/S mode.
>>>>>
>>>>>Don't make things to complicated!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>So the problem is that, when you try to retrieve a connection, it
>>>>>>
>>>>>>
>>>>should
>>>>
>>>>
>>>>>>return an available one from the pool, instead of a fixed one. Has
>>>>>>
>>>>>>
>>>>anyone
>>>>
>>>>
>>>>>>done such an example?
>>>>>>And so, if the connection retrieved is dynamic, how to enable the
>>>>>>
>>cache
>>
>>>>of
>>>>
>>>>
>>>>>>perparedstatement?
>>>>>>
>>>>>>
>>>>>As I told you before: The OJB PreparedStatement cache will check if
>>>>>
> the
> 
>>>>>underlying connections are still valid. Just release your connections
>>>>>
> to
> 
>>>>>the ConnectionPool if you feel like. OJB will do the rest.
>>>>>
>>>>>BUT: please don't complain when performance goes down !!!
>>>>>
>>>>>
>>>>>HTH,
>>>>>
>>>>>Thomas
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Thanks a lot,
>>>>>>John W
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>----- Original Message -----
>>>>>>>From: "Thomas Mahler" <tho...@ho...>
>>>>>>>To: "ojb" <obj...@li...>
>>>>>>>Sent: Saturday, March 09, 2002 3:10 AM
>>>>>>>Subject: [Fwd: Re: [OJB-developers] About connection pool and
>>>>>>>preparedstatement cache]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>John Wang wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>I noticed that for a class, it  can only use the same connection,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>even for
>>>>>>>>
>>>>>>>>
>>>>>>>>>different users. So when 2 users are accessing the same class
>>>>>>>>>
>>>>>>>>>
>>>>>>>>objects, they
>>>>>>>>
>>>>>>>>
>>>>>>>>>will share the same connection, and may cause some problem, right?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>Why should this be problematic? a PersistenceBroker handles only
>>>>>>>>
> one
> 
>>>>>>>>JDBC transaction at a time. If two threads (or users) are working
>>>>>>>>
>>with
>>
>>>>>>>>the the same broker only one of them can perform transactional
>>>>>>>>operations at a time.
>>>>>>>>
>>>>>>>>If two threads (or users) need to work in parallel they have to
>>>>>>>>
>>obtain
>>
>>>>>>>>individual PersistenceBrokers. As each PersistenceBroker holds its
>>>>>>>>
>>own
>>
>>>>>>>>Connections there is again no problem here.
>>>>>>>>
>>>>>>>>What kind of problems are you thinking of?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>In ConnectionManager.getConnectionForClassDescriptor, it will get
>>>>>>>>>
>>>>>>>>>
>>>>>>from
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>hashmap, so it will return the same for a classdescriptor.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>Yes, per broker it's possible to have a dedicated Connection for
>>>>>>>>
> each
> 
>>>>>>>>persistent Class. but in general all classes share a default
>>>>>>>>
>>>>>>>>
>>>>connection.
>>>>
>>>>
>>>>>>>>>The preparedstatement is also cached in the StatementsforClass,
>>>>>>>>>
>>>>>>>>>
>>>>which
>>>>
>>>>
>>>>>>>is
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>good. I am just wondering whether it can live outside of a
>>>>>>>>>
>>>>>>>>>
>>>>>>connection.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>>PreparedStatements depend on a active Connection. Thus before using
>>>>>>>>
> a
> 
>>>>>>>>cached PreparedStatement OJB always checks if the Connection is
>>>>>>>>
> still
> 
>>>>>>>>
>>>>>>>alive.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>HTH,
>>>>>>>>
>>>>>>>>Thomas
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Thanks a lot,
>>>>>>>>>John W
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>----- Original Message -----
>>>>>>>>>From: "Georg Schneider" <ge...@me...>
>>>>>>>>>To: <obj...@li...>
>>>>>>>>>Sent: Friday, March 08, 2002 1:33 AM
>>>>>>>>>Subject: [OJB-developers] dynamic proxies
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>Hi,
>>>>>>>>>>
>>>>>>>>>>I just implemented a few lines to enable dynamic proxies to also
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>implement
>>>>>>>>
>>>>>>>>
>>>>>>>>>>interfaces which are implemented by classes further up the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>inheritance
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>hierarchy. I just added the following lines in
>>>>>>>>>>
> RepositoryXmlHandler
> 
>>>>>>>>in the
>>>>>>>>
>>>>>>>>
>>>>>>>>>>method getDynamicProxyClass:
>>>>>>>>>>
>>>>>>>>>>          Class[] interfaces = clazz.getInterfaces();
>>>>>>>>>>  //added from here on
>>>>>>>>>>  Class superClass = clazz;
>>>>>>>>>>
>>>>>>>>>>  while((superClass = superClass.getSuperclass()) != null) {
>>>>>>>>>>
>>>>>>>>>>Class[] superInterfaces = superClass.getInterfaces();
>>>>>>>>>>
>>>>>>>>>>Class[] combInterfaces =
>>>>>>>>>>  new Class[interfaces.length +
>>>>>>>>>>    superInterfaces.length];
>>>>>>>>>>System.arraycopy(interfaces,0,combInterfaces,0,
>>>>>>>>>>interfaces.length);
>>>>>>>>>>System.arraycopy(superInterfaces,0,combInterfaces,
>>>>>>>>>>interfaces.length,
>>>>>>>>>>superInterfaces.length);
>>>>>>>>>>interfaces = combInterfaces;
>>>>>>>>>>  }
>>>>>>>>>>  //end added
>>>>>>>>>>
>>>>>>>>>>          Class proxyClass = Proxy.getProxyClass(
>>>>>>>>>>                  clazz.getClassLoader(), interfaces);
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Regards
>>>>>>>>>>
>>>>>>>>>>Georg
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>_______________________________________________
>>>>>>>>>>Objectbridge-developers mailing list
>>>>>>>>>>Obj...@li...
>>>>>>>>>>
>>>>>>>>https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>_______________________________________________
>>>>>>>>>Objectbridge-developers mailing list
>>>>>>>>>Obj...@li...
>>>>>>>>>
>>>>>>>https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>_______________________________________________
>>>>>>>>Objectbridge-developers mailing list
>>>>>>>>Obj...@li...
>>>>>>>>
>>>>>>https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>>>>>>
>>>>>>>>
>>>>>>_______________________________________________
>>>>>>Objectbridge-developers mailing list
>>>>>>Obj...@li...
>>>>>>https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>_______________________________________________
>>>>Objectbridge-developers mailing list
>>>>Obj...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
> 
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 
> 
> 
> 

Re: [OJB-developers] About connection pool and preparedstatement cache]

[John W. <hw...@re...>]

Well, sorry for my midunderstanding before, I think the connectionmanager
belongs the persistencebroker, so if several users comes in, they use the
different persistencebroker, thus use different connectionmanager and jdbc
connection.
How to specify a type of JDBC connection for a class descriptor in
configuration file? Usually it used the "default" one, right?
thankx,
John W

----- Original Message -----
From: "John Wang" <hw...@re...>
To: <obj...@li...>
Sent: Thursday, March 14, 2002 11:52 AM
Subject: Re: [OJB-developers] About connection pool and preparedstatement
cache]


> Thomas:
>    When I read the source code, I am still confused about the relationship
> about  the management of jdbc connections. It seems like that the
connection
> is allocated based on the classdescriptor, though I am not sure how to
> dedicate a JdbcConnectionDescriptor to a classdescriptor, but suppose it
is
> possible, I am still confused about the way jdbc connection is used.
>    Usually in web application, several users may access the same classes
at
> the same time, say updating a different article, and they should be
handled
> by different jdbc connection. But according to
> ConnectionManager.getConnectionForClassDescriptor() method, it always
return
> the same connection for a single type of classes. So if two users are
> accessing the article class at the same time, they will share the same
> connection. That's what I am worried about.
>    Hope you can explain a litter bit more,
>    Best regards,
> John W
>
> ----- Original Message -----
> From: "Thomas Mahler" <tho...@ho...>
> To: "John Wang" <hw...@re...>
> Sent: Monday, March 11, 2002 10:38 PM
> Subject: Re: [OJB-developers] About connection pool and preparedstatement
> cache]
>
>
> > Hi again John,
> >
> > John Wang wrote:
> >
> > > Thanks for your response.
> > >
> > >
> > >>. If you are
> > >>running a servlet engine and your machine is powerful enough the best
> > >>thing is to run OJB within the same VM as the servlet engine.
> > >>
> > >
> > > I agree with you. I am just wondering how to support multiple
concurrent
> > > requests in the servlet engine. Say user A's request comes in, the
> servlet
> > > will use the PersistenceBrokerImpl and its connection, before the
> servlet
> > > finishes this request and commit his changes, user B's request comes
in,
> > > should he create a new PersistenceBrokerImpl and a new connection? I
> assume
> > > that he can't use the same PersistenceBrokerImpl and the connection
with
> > > User A, because user A hasn't committed the changes yet.
> >
> >
> > Yes simply obtain a new PersistenceBroker to perform transactions in
> > parallel. Use PersistenceBrokerFactory for this.
> > It is important to release broker instances after use with
> > PersistenceBrokerFactory.releaseInstance(broker).
> >
> > Of course it may also be a valid approach to serialize all user
> > transactions. That is use just a single broker instance. Thus your app
> > must wait for proccessing B until A's  transaction is commited.
> >
> > hth,
> >
> > Thomas
> >
> >
> > > Hope it is clear,
> > > thanks again,
> > > John W
> > >
> > >
> > > ----- Original Message -----
> > > From: "Thomas Mahler" <tho...@ho...>
> > > To: "John Wang" <hw...@re...>
> > > Cc: <obj...@li...>
> > > Sent: Monday, March 11, 2002 11:35 AM
> > > Subject: Re: [OJB-developers] About connection pool and
> preparedstatement
> > > cache]
> > >
> > >
> > >
> > >>Hi again John
> > >>
> > >>John Wang wrote:
> > >>
> > >>
> > >>> I am thinking that in a web application development, usually we use
a
> > >>> connection pool, and get a connection from there.
> > >>>
> > >>
> > >>OK
> > >>
> > >>
> > >>>So in the app server, say
> > >>> tomcat, need to maintain a pool of connections(I guess we should use
> > >>> PersistenceBrokerImpl for OJB), and use app server's load balancer
and
> > >>>JOB's
> > >>> distributed cache to improve the performance and workload. I am very
> > >>> concerned about the performance of OJB's C/S mode and other network
> > >>>
> > > calle
> > >
> > >>> mechanisms(like ejb), I am thinking that this may be a better
> approach.
> > >>>
> > > Do
> > >
> > >>> you agree with me?
> > >>>
> > >>
> > >>I'm not sure if I got you right. But I give it a try:
> > >>The OJB way of working with PreparedStatements is to cache them for
> > >>maximum performance. To keep a PreparedStatement hot the underlying
Jdbc
> > >>Connection must be active.
> > >>Thus if you return the connection object used by the OJB broker to the
> > >>app servers pool OJBs caching of PreparedStatements would be
> superfluous.
> > >>
> > >>Before re-using a PreparedStatement OJB checks if the connection is
> > >>still alive.
> > >>Thus it is totally safe to release the Connection object to the app
> > >>servers pool.
> > >>
> > >>Feel free to do this! But imho it will have a negative performance
> impact.
> > >>
> > >>I don't understand why you bring in the OJB C/S mode here. If you are
> > >>running a servlet engine and your machine is powerful enough the best
> > >>thing is to run OJB within the same VM as the servlet engine.
> > >>
> > >>If you are forced to scale, that is run Servlet Engine and OJB on
> > >>multiple machines you must use the OJB C/S mode.
> > >>
> > >>Don't make things to complicated!
> > >>
> > >>
> > >>
> > >>> So the problem is that, when you try to retrieve a connection, it
> > >>>
> > > should
> > >
> > >>> return an available one from the pool, instead of a fixed one. Has
> > >>>
> > > anyone
> > >
> > >>> done such an example?
> > >>> And so, if the connection retrieved is dynamic, how to enable the
> cache
> > >>>
> > > of
> > >
> > >>> perparedstatement?
> > >>>
> > >>
> > >>As I told you before: The OJB PreparedStatement cache will check if
the
> > >>underlying connections are still valid. Just release your connections
to
> > >>the ConnectionPool if you feel like. OJB will do the rest.
> > >>
> > >>BUT: please don't complain when performance goes down !!!
> > >>
> > >>
> > >>HTH,
> > >>
> > >>Thomas
> > >>
> > >>
> > >>
> > >>> Thanks a lot,
> > >>> John W
> > >>>
> > >>>
> > >>>
> > >>>>----- Original Message -----
> > >>>>From: "Thomas Mahler" <tho...@ho...>
> > >>>>To: "ojb" <obj...@li...>
> > >>>>Sent: Saturday, March 09, 2002 3:10 AM
> > >>>>Subject: [Fwd: Re: [OJB-developers] About connection pool and
> > >>>>preparedstatement cache]
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>John Wang wrote:
> > >>>>>
> > >>>>>
> > >>>>>>I noticed that for a class, it  can only use the same connection,
> > >>>>>>
> > >>>>>even for
> > >>>>>
> > >>>>>>different users. So when 2 users are accessing the same class
> > >>>>>>
> > >>>>>objects, they
> > >>>>>
> > >>>>>>will share the same connection, and may cause some problem, right?
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>Why should this be problematic? a PersistenceBroker handles only
one
> > >>>>>JDBC transaction at a time. If two threads (or users) are working
> with
> > >>>>>the the same broker only one of them can perform transactional
> > >>>>>operations at a time.
> > >>>>>
> > >>>>>If two threads (or users) need to work in parallel they have to
> obtain
> > >>>>>individual PersistenceBrokers. As each PersistenceBroker holds its
> own
> > >>>>>Connections there is again no problem here.
> > >>>>>
> > >>>>>What kind of problems are you thinking of?
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>In ConnectionManager.getConnectionForClassDescriptor, it will get
> > >>>>>>
> > >>>from
> > >>>
> > >>>
> > >>>>>>hashmap, so it will return the same for a classdescriptor.
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>Yes, per broker it's possible to have a dedicated Connection for
each
> > >>>>>persistent Class. but in general all classes share a default
> > >>>>>
> > > connection.
> > >
> > >>>>>
> > >>>>>>The preparedstatement is also cached in the StatementsforClass,
> > >>>>>>
> > > which
> > >
> > >>>>is
> > >>>>
> > >>>>
> > >>>>>>good. I am just wondering whether it can live outside of a
> > >>>>>>
> > >>>connection.
> > >>>
> > >>>
> > >>>>>
> > >>>>>
> > >>>>>PreparedStatements depend on a active Connection. Thus before using
a
> > >>>>>cached PreparedStatement OJB always checks if the Connection is
still
> > >>>>>
> > >>>>>
> > >>>>alive.
> > >>>>
> > >>>>
> > >>>>>HTH,
> > >>>>>
> > >>>>>Thomas
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>Thanks a lot,
> > >>>>>>John W
> > >>>>>>
> > >>>>>>
> > >>>>>>----- Original Message -----
> > >>>>>>From: "Georg Schneider" <ge...@me...>
> > >>>>>>To: <obj...@li...>
> > >>>>>>Sent: Friday, March 08, 2002 1:33 AM
> > >>>>>>Subject: [OJB-developers] dynamic proxies
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>>Hi,
> > >>>>>>>
> > >>>>>>>I just implemented a few lines to enable dynamic proxies to also
> > >>>>>>>
> > >>>>>implement
> > >>>>>
> > >>>>>>>interfaces which are implemented by classes further up the
> > >>>>>>>
> > >>>inheritance
> > >>>
> > >>>
> > >>>>>>>hierarchy. I just added the following lines in
RepositoryXmlHandler
> > >>>>>>>
> > >>>>>in the
> > >>>>>
> > >>>>>>>method getDynamicProxyClass:
> > >>>>>>>
> > >>>>>>>           Class[] interfaces = clazz.getInterfaces();
> > >>>>>>>   //added from here on
> > >>>>>>>   Class superClass = clazz;
> > >>>>>>>
> > >>>>>>>   while((superClass = superClass.getSuperclass()) != null) {
> > >>>>>>>
> > >>>>>>>Class[] superInterfaces = superClass.getInterfaces();
> > >>>>>>>
> > >>>>>>>Class[] combInterfaces =
> > >>>>>>>   new Class[interfaces.length +
> > >>>>>>>     superInterfaces.length];
> > >>>>>>>System.arraycopy(interfaces,0,combInterfaces,0,
> > >>>>>>>interfaces.length);
> > >>>>>>>System.arraycopy(superInterfaces,0,combInterfaces,
> > >>>>>>>interfaces.length,
> > >>>>>>>superInterfaces.length);
> > >>>>>>>interfaces = combInterfaces;
> > >>>>>>>   }
> > >>>>>>>   //end added
> > >>>>>>>
> > >>>>>>>           Class proxyClass = Proxy.getProxyClass(
> > >>>>>>>                   clazz.getClassLoader(), interfaces);
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>Regards
> > >>>>>>>
> > >>>>>>>Georg
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>_______________________________________________
> > >>>>>>>Objectbridge-developers mailing list
> > >>>>>>>Obj...@li...
> >
>
>>>>>>>https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>>_______________________________________________
> > >>>>>>Objectbridge-developers mailing list
> > >>>>>>Obj...@li...
> >
>>>>>>https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>_______________________________________________
> > >>>>>Objectbridge-developers mailing list
> > >>>>>Obj...@li...
> >
>>>>>https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> > >>>>>
> > >>>>>
> > >>>
> > >>>_______________________________________________
> > >>>Objectbridge-developers mailing list
> > >>>Obj...@li...
> > >>>https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >
> > >
> > > _______________________________________________
> > > Objectbridge-developers mailing list
> > > Obj...@li...
> > > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> > >
> > >
> > >
> > >
> >
> >
>

Re: [OJB-developers] About connection pool and preparedstatement cache]

[John W. <hw...@re...>]

Thomas:
   When I read the source code, I am still confused about the relationship
about  the management of jdbc connections. It seems like that the connection
is allocated based on the classdescriptor, though I am not sure how to
dedicate a JdbcConnectionDescriptor to a classdescriptor, but suppose it is
possible, I am still confused about the way jdbc connection is used.
   Usually in web application, several users may access the same classes at
the same time, say updating a different article, and they should be handled
by different jdbc connection. But according to
ConnectionManager.getConnectionForClassDescriptor() method, it always return
the same connection for a single type of classes. So if two users are
accessing the article class at the same time, they will share the same
connection. That's what I am worried about.
   Hope you can explain a litter bit more,
   Best regards,
John W

----- Original Message -----
From: "Thomas Mahler" <tho...@ho...>
To: "John Wang" <hw...@re...>
Sent: Monday, March 11, 2002 10:38 PM
Subject: Re: [OJB-developers] About connection pool and preparedstatement
cache]


> Hi again John,
>
> John Wang wrote:
>
> > Thanks for your response.
> >
> >
> >>. If you are
> >>running a servlet engine and your machine is powerful enough the best
> >>thing is to run OJB within the same VM as the servlet engine.
> >>
> >
> > I agree with you. I am just wondering how to support multiple concurrent
> > requests in the servlet engine. Say user A's request comes in, the
servlet
> > will use the PersistenceBrokerImpl and its connection, before the
servlet
> > finishes this request and commit his changes, user B's request comes in,
> > should he create a new PersistenceBrokerImpl and a new connection? I
assume
> > that he can't use the same PersistenceBrokerImpl and the connection with
> > User A, because user A hasn't committed the changes yet.
>
>
> Yes simply obtain a new PersistenceBroker to perform transactions in
> parallel. Use PersistenceBrokerFactory for this.
> It is important to release broker instances after use with
> PersistenceBrokerFactory.releaseInstance(broker).
>
> Of course it may also be a valid approach to serialize all user
> transactions. That is use just a single broker instance. Thus your app
> must wait for proccessing B until A's  transaction is commited.
>
> hth,
>
> Thomas
>
>
> > Hope it is clear,
> > thanks again,
> > John W
> >
> >
> > ----- Original Message -----
> > From: "Thomas Mahler" <tho...@ho...>
> > To: "John Wang" <hw...@re...>
> > Cc: <obj...@li...>
> > Sent: Monday, March 11, 2002 11:35 AM
> > Subject: Re: [OJB-developers] About connection pool and
preparedstatement
> > cache]
> >
> >
> >
> >>Hi again John
> >>
> >>John Wang wrote:
> >>
> >>
> >>> I am thinking that in a web application development, usually we use a
> >>> connection pool, and get a connection from there.
> >>>
> >>
> >>OK
> >>
> >>
> >>>So in the app server, say
> >>> tomcat, need to maintain a pool of connections(I guess we should use
> >>> PersistenceBrokerImpl for OJB), and use app server's load balancer and
> >>>JOB's
> >>> distributed cache to improve the performance and workload. I am very
> >>> concerned about the performance of OJB's C/S mode and other network
> >>>
> > calle
> >
> >>> mechanisms(like ejb), I am thinking that this may be a better
approach.
> >>>
> > Do
> >
> >>> you agree with me?
> >>>
> >>
> >>I'm not sure if I got you right. But I give it a try:
> >>The OJB way of working with PreparedStatements is to cache them for
> >>maximum performance. To keep a PreparedStatement hot the underlying Jdbc
> >>Connection must be active.
> >>Thus if you return the connection object used by the OJB broker to the
> >>app servers pool OJBs caching of PreparedStatements would be
superfluous.
> >>
> >>Before re-using a PreparedStatement OJB checks if the connection is
> >>still alive.
> >>Thus it is totally safe to release the Connection object to the app
> >>servers pool.
> >>
> >>Feel free to do this! But imho it will have a negative performance
impact.
> >>
> >>I don't understand why you bring in the OJB C/S mode here. If you are
> >>running a servlet engine and your machine is powerful enough the best
> >>thing is to run OJB within the same VM as the servlet engine.
> >>
> >>If you are forced to scale, that is run Servlet Engine and OJB on
> >>multiple machines you must use the OJB C/S mode.
> >>
> >>Don't make things to complicated!
> >>
> >>
> >>
> >>> So the problem is that, when you try to retrieve a connection, it
> >>>
> > should
> >
> >>> return an available one from the pool, instead of a fixed one. Has
> >>>
> > anyone
> >
> >>> done such an example?
> >>> And so, if the connection retrieved is dynamic, how to enable the
cache
> >>>
> > of
> >
> >>> perparedstatement?
> >>>
> >>
> >>As I told you before: The OJB PreparedStatement cache will check if the
> >>underlying connections are still valid. Just release your connections to
> >>the ConnectionPool if you feel like. OJB will do the rest.
> >>
> >>BUT: please don't complain when performance goes down !!!
> >>
> >>
> >>HTH,
> >>
> >>Thomas
> >>
> >>
> >>
> >>> Thanks a lot,
> >>> John W
> >>>
> >>>
> >>>
> >>>>----- Original Message -----
> >>>>From: "Thomas Mahler" <tho...@ho...>
> >>>>To: "ojb" <obj...@li...>
> >>>>Sent: Saturday, March 09, 2002 3:10 AM
> >>>>Subject: [Fwd: Re: [OJB-developers] About connection pool and
> >>>>preparedstatement cache]
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>John Wang wrote:
> >>>>>
> >>>>>
> >>>>>>I noticed that for a class, it  can only use the same connection,
> >>>>>>
> >>>>>even for
> >>>>>
> >>>>>>different users. So when 2 users are accessing the same class
> >>>>>>
> >>>>>objects, they
> >>>>>
> >>>>>>will share the same connection, and may cause some problem, right?
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>Why should this be problematic? a PersistenceBroker handles only one
> >>>>>JDBC transaction at a time. If two threads (or users) are working
with
> >>>>>the the same broker only one of them can perform transactional
> >>>>>operations at a time.
> >>>>>
> >>>>>If two threads (or users) need to work in parallel they have to
obtain
> >>>>>individual PersistenceBrokers. As each PersistenceBroker holds its
own
> >>>>>Connections there is again no problem here.
> >>>>>
> >>>>>What kind of problems are you thinking of?
> >>>>>
> >>>>>
> >>>>>
> >>>>>>In ConnectionManager.getConnectionForClassDescriptor, it will get
> >>>>>>
> >>>from
> >>>
> >>>
> >>>>>>hashmap, so it will return the same for a classdescriptor.
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>Yes, per broker it's possible to have a dedicated Connection for each
> >>>>>persistent Class. but in general all classes share a default
> >>>>>
> > connection.
> >
> >>>>>
> >>>>>>The preparedstatement is also cached in the StatementsforClass,
> >>>>>>
> > which
> >
> >>>>is
> >>>>
> >>>>
> >>>>>>good. I am just wondering whether it can live outside of a
> >>>>>>
> >>>connection.
> >>>
> >>>
> >>>>>
> >>>>>
> >>>>>PreparedStatements depend on a active Connection. Thus before using a
> >>>>>cached PreparedStatement OJB always checks if the Connection is still
> >>>>>
> >>>>>
> >>>>alive.
> >>>>
> >>>>
> >>>>>HTH,
> >>>>>
> >>>>>Thomas
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Thanks a lot,
> >>>>>>John W
> >>>>>>
> >>>>>>
> >>>>>>----- Original Message -----
> >>>>>>From: "Georg Schneider" <ge...@me...>
> >>>>>>To: <obj...@li...>
> >>>>>>Sent: Friday, March 08, 2002 1:33 AM
> >>>>>>Subject: [OJB-developers] dynamic proxies
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Hi,
> >>>>>>>
> >>>>>>>I just implemented a few lines to enable dynamic proxies to also
> >>>>>>>
> >>>>>implement
> >>>>>
> >>>>>>>interfaces which are implemented by classes further up the
> >>>>>>>
> >>>inheritance
> >>>
> >>>
> >>>>>>>hierarchy. I just added the following lines in RepositoryXmlHandler
> >>>>>>>
> >>>>>in the
> >>>>>
> >>>>>>>method getDynamicProxyClass:
> >>>>>>>
> >>>>>>>           Class[] interfaces = clazz.getInterfaces();
> >>>>>>>   //added from here on
> >>>>>>>   Class superClass = clazz;
> >>>>>>>
> >>>>>>>   while((superClass = superClass.getSuperclass()) != null) {
> >>>>>>>
> >>>>>>>Class[] superInterfaces = superClass.getInterfaces();
> >>>>>>>
> >>>>>>>Class[] combInterfaces =
> >>>>>>>   new Class[interfaces.length +
> >>>>>>>     superInterfaces.length];
> >>>>>>>System.arraycopy(interfaces,0,combInterfaces,0,
> >>>>>>>interfaces.length);
> >>>>>>>System.arraycopy(superInterfaces,0,combInterfaces,
> >>>>>>>interfaces.length,
> >>>>>>>superInterfaces.length);
> >>>>>>>interfaces = combInterfaces;
> >>>>>>>   }
> >>>>>>>   //end added
> >>>>>>>
> >>>>>>>           Class proxyClass = Proxy.getProxyClass(
> >>>>>>>                   clazz.getClassLoader(), interfaces);
> >>>>>>>
> >>>>>>>
> >>>>>>>Regards
> >>>>>>>
> >>>>>>>Georg
> >>>>>>>
> >>>>>>>
> >>>>>>>_______________________________________________
> >>>>>>>Objectbridge-developers mailing list
> >>>>>>>Obj...@li...
>
>>>>>>>https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>_______________________________________________
> >>>>>>Objectbridge-developers mailing list
> >>>>>>Obj...@li...
> >>>>>>https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>_______________________________________________
> >>>>>Objectbridge-developers mailing list
> >>>>>Obj...@li...
> >>>>>https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> >>>>>
> >>>>>
> >>>
> >>>_______________________________________________
> >>>Objectbridge-developers mailing list
> >>>Obj...@li...
> >>>https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> > _______________________________________________
> > Objectbridge-developers mailing list
> > Obj...@li...
> > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> >
> >
> >
> >
>
>