objectbridge-developers Mailing List for ObJectRelationalBridge (Page 32)
Brought to you by:
thma
Menu
▾
▴
objectbridge-developers — public list for developer issues
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(14) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(33) |
Feb
(8) |
Mar
(3) |
Apr
(1) |
May
(18) |
Jun
(6) |
Jul
(15) |
Aug
(71) |
Sep
(29) |
Oct
(43) |
Nov
(77) |
Dec
(54) |
| 2002 |
Jan
(54) |
Feb
(147) |
Mar
(144) |
Apr
(163) |
May
(307) |
Jun
(240) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Mahler T. <tho...@it...> - 2002-03-14 07:32:32
|
I think it would even be better to have the C/S tests automated. I have started to work on this (you'll find some traces in the "junit" target in build.xml) but did not get things working right now. Thomas > -----Urspr=FCngliche Nachricht----- > Von: Eric Bieschke [mailto:EBi...@sa...] > Gesendet: Mittwoch, 13. M=E4rz 2002 20:13 > An: Mahler Thomas; Joa...@tp...; > obj...@li... > Betreff: Re: [OJB-developers] C/S JUnit tests >=20 >=20 > This would be extremely useful to have added to the OJB = documentation. >=20 > - Eric >=20 > ----- Original Message -----=20 > Subject: AW: [OJB-developers] C/S JUnit tests >=20 >=20 > Hi Joachim, >=20 > > Hy, > >=20 > > are there any JUnit tests that test the C/S-Model? As I'm doing = some > > refactoring in this area to allow simple a implementation of the > > PersistenceBrokerServlet. Unfortunately I don't know enough=20 > > of JUnit to > > write those tests myself (I know, I better have to learn it, now!). > > >=20 > Currently there are no special JUnit tests for the C/S mode. > To test C/S mode I do the following: > 0. compile everything with build.sh main > 1. Switch to server mode in OJB.properties. > 2. Setup test database with build.sh tests > 3. startup server with server.sh > 4. run all JUnit tests with build.sh junit >=20 > HTH, >=20 > Thomas > =20 > > regards > > Joachim Sauer >=20 >=20 |
|
From: Thomas M. <tho...@ho...> - 2002-03-13 21:26:43
|
Hy again Joachim,
Joa...@tp... wrote:
<snip executive summary>
> --- begin gory details block ---
> right now I'm deeply into the C/S-model of ObjectBridge.
welcome to the club of hardcore ojb hackers !
> But I'm having a
> problem. The JUnit tests worked well in singlevm mode on mysql (except for
> the one Test that failes 'cause MySQL handles CLOBs in a non-standard way),
> but as soon as I started it in Client/Server mode it started to act up.
Can you imagine all the pain I suffered to get this stuff running for
the first time?
>
> First of all I searched 2 hours for an error until I noticed that my
> experimental support for global UIDs in SequenceManagerHighLowImpl (which
A side note: OJB provides a GUID class in ojb.broker.util.GUID. Maybe you find it useful.
> was a very, very ugly hack) wreaked havoc, but after this was fixed I still
> had problems. After some further investigation (and some prayer that the
> cause-exception handling of 1.4 will become more common) I found out that
> the server choked on .store() outside of transactions (which I think is
> legal, at least in the JUnit tests in singlevm mode it works).
>
> The problem was the code
>
> broker.store(arg1, (ObjectModification) arg2);
> ((PersistenceBrokerImpl) broker).checkPoint();
>
> i changed it to
>
> broker.store(arg1, (ObjectModification) arg2);
> if (broker.isInTransaction()) {
> ((PersistenceBrokerImpl) broker).checkPoint();
> }
>
> which at least solved the symptoms. Is the checkPoint really necessary?
>
Oops. I thought I kicked out the checkpoint stuff already. I think it's
pretty superfluous.
> Later on I found one more problem: When the Client executed a
> beginTransaction after already haveing done some talking with the server
> (outside of an Transaction) the Server chocked, 'cause it thought that the
> fact that the client already got an brokerId automatically ment that it
> already had a running transaction (which is wrong, AFAICS).
Mmh, my initial idea was to only assign an id once a tx was started. As
this is the only reason why a client should be served by the same broker
instance. I don't see why we should assign a brokerid (which is
something like a session cookie) outside a tx.
>
> After I got the default C/S-System to run I refactored the RequestProcessor
> to take out the Socket-Handling code to allow me to reuse it for my
> soon-to-come PersistenceBrokerServlet.
That's a very good refactoring !
> The Socket Handling Code became a
> new class ConnectionHandler (I'd have made it a private inner class of
> PersistenceBrokerServer, but I know that most other ppl don't like this
> very much).
As you will have noticed, I did not use inner classes. (Jakob uses them
in certain places). I don't use inner classes as some IDE's don't
provide good support for visualizing inner classes. But I guess it's OK
to have inner classes for certain details.
>
> Then I started refactoring dispatch(). Most of the methods like store(),
> open(), getUniqeId() have only two lines difference (the common code beeing
> the brokerId-is-still--1-code and the exception handling). I moved both the
> brokerId-handling code and the exception handlig out of the specific
> functions and as the remaining functions all had only one or two lines left
> I inlined them into the call, saving some hundered lines of codes.
this is a very good refactoring too!
>I know
> this is a matter of taste, but I prefer it this way, I'd like to hear your
> oppinion on this one.
>
IMHO this was really a "smelly" piece of code !
> Basically the major improvement (IMHO) was that I changed the broker
> allocation scheme. Now if the client provides a brokerId this broker is
> always used (which opens a huge security hole, but this was not different
> before).
I did not bother with security issues in my initial design.
The brokerId is only a kind of "cookie" to identify a client transaction.
To make this secure we "simply" have to ensure that only the server can
generate such transaction IDs and that the client can't produce fake
ID's to contact brokers serving other transactions.
(This is left as an exercise to the interested reader ;-))
>At the end of the-function-formerly-known-as-dispatched (which I
> renamed to execute, to reflect its new functionality) the broker is
> released, unless it has a running transaction (which only happens, when the
> client has requested a beginTransaction). This seems to work fairly well.
Yes that should be OK!
> At least I now pass all JUnit Test while in Client/Server mode (except of
> course PersistenceBrokerTest.testEscaping which MySQL can't pass).
>
Did you're changes also pass the ODMG tests? They contain some special
tests not checked in the broker tests.
> before I forget it: one functionality was lost and I don't know yet what to
> do about it: srvPing now no longer can use connection.getLocalAddress() as
> it is handled in RequestProcessor which no longer knows about the socket.
>
This can be replaced by InetAddress.getLocalHost().getHostAddress().
> Unfortunately I can't make a reasonable diff, due to the newline-problem in
> CVS (it allways produces a diff that is twice the size of the files to be
> diffed), so I'll just include a .zip with the two changed files
> (PersistenceBrokerServer and RequestProcessor) and the new File
> (ConnectionHandler).
Joachim, I guess it would be much simpler if you check in your code
directly into the CVS archive. What do you think?
If you want to have developer access to the CVS repository please tell
me your SourceForge user name and I will setup everything for you!
Of course if you prefer to send in your code via email this is also OK
for me.
thanks for your efforts !
Thomas
> --- end gory details block ---
>
> btw, shouldn't static finals (as in PBMethodIndex) be written in
> all-uppercase (i.e. ABORT_TRANSACTION instead of abortTransaction)?
>
Yes, it would look much more professional that way ;-)
|
|
From: <Joa...@tp...> - 2002-03-13 19:46:24
|
hy,
okay, this mail grew while I worked on the C/S-model (I started it, when I
thought it was finished, but finished it just 2 hours later), so it might
be a bit confuse and too long to be usefull, so i'll just put an "executive
summary" right at the top ;-)
--- begin executive summary block ---
I did some major refactoring to RequestProcessor, extracting a new class
ConnectionHandler that does all the socket-stuff. This will allow me to
reuse RequestProcessor in my soon-to-come PersistenceBrokerServlet. While
doing this I also cleaned up the RequestProcessor and gave it a much
cleaner structure (IMHO). Of course this also required some modification to
the PersistenceBrokerServer, but they were minimal (no changes to the
PersistenceBrokerClient were necessary, but will be, when I add support for
the Servlet).
The result works great for me. All JUnit tests pass (except for the
mandatory failed test using MySQL) using C/S. The only drawback I see is
that srvPing lost a minimal amount of functionality, but that seems to be a
diagnostic function.
Just unzip the attached server.zip to src\ojb\broker\server to try the new
classes.
--- end executive summary block ---
For those, who are willing to follow me through my odyssey here are the
gory details:
--- begin gory details block ---
right now I'm deeply into the C/S-model of ObjectBridge. But I'm having a
problem. The JUnit tests worked well in singlevm mode on mysql (except for
the one Test that failes 'cause MySQL handles CLOBs in a non-standard way),
but as soon as I started it in Client/Server mode it started to act up.
First of all I searched 2 hours for an error until I noticed that my
experimental support for global UIDs in SequenceManagerHighLowImpl (which
was a very, very ugly hack) wreaked havoc, but after this was fixed I still
had problems. After some further investigation (and some prayer that the
cause-exception handling of 1.4 will become more common) I found out that
the server choked on .store() outside of transactions (which I think is
legal, at least in the JUnit tests in singlevm mode it works).
The problem was the code
broker.store(arg1, (ObjectModification) arg2);
((PersistenceBrokerImpl) broker).checkPoint();
i changed it to
broker.store(arg1, (ObjectModification) arg2);
if (broker.isInTransaction()) {
((PersistenceBrokerImpl) broker).checkPoint();
}
which at least solved the symptoms. Is the checkPoint really necessary?
Later on I found one more problem: When the Client executed a
beginTransaction after already haveing done some talking with the server
(outside of an Transaction) the Server chocked, 'cause it thought that the
fact that the client already got an brokerId automatically ment that it
already had a running transaction (which is wrong, AFAICS).
After I got the default C/S-System to run I refactored the RequestProcessor
to take out the Socket-Handling code to allow me to reuse it for my
soon-to-come PersistenceBrokerServlet. The Socket Handling Code became a
new class ConnectionHandler (I'd have made it a private inner class of
PersistenceBrokerServer, but I know that most other ppl don't like this
very much).
Then I started refactoring dispatch(). Most of the methods like store(),
open(), getUniqeId() have only two lines difference (the common code beeing
the brokerId-is-still--1-code and the exception handling). I moved both the
brokerId-handling code and the exception handlig out of the specific
functions and as the remaining functions all had only one or two lines left
I inlined them into the call, saving some hundered lines of codes. I know
this is a matter of taste, but I prefer it this way, I'd like to hear your
oppinion on this one.
Basically the major improvement (IMHO) was that I changed the broker
allocation scheme. Now if the client provides a brokerId this broker is
always used (which opens a huge security hole, but this was not different
before). At the end of the-function-formerly-known-as-dispatched (which I
renamed to execute, to reflect its new functionality) the broker is
released, unless it has a running transaction (which only happens, when the
client has requested a beginTransaction). This seems to work fairly well.
At least I now pass all JUnit Test while in Client/Server mode (except of
course PersistenceBrokerTest.testEscaping which MySQL can't pass).
before I forget it: one functionality was lost and I don't know yet what to
do about it: srvPing now no longer can use connection.getLocalAddress() as
it is handled in RequestProcessor which no longer knows about the socket.
Unfortunately I can't make a reasonable diff, due to the newline-problem in
CVS (it allways produces a diff that is twice the size of the files to be
diffed), so I'll just include a .zip with the two changed files
(PersistenceBrokerServer and RequestProcessor) and the new File
(ConnectionHandler).
--- end gory details block ---
btw, shouldn't static finals (as in PBMethodIndex) be written in
all-uppercase (i.e. ABORT_TRANSACTION instead of abortTransaction)?
regards
Joachim Sauer
P.S.: You don't need to send the message to both the list and me, I'm
allready subscribed ;-)
(See attached file: server.zip) |
|
From: Eric B. <EBi...@sa...> - 2002-03-13 19:23:54
|
This would be extremely useful to have added to the OJB documentation. - Eric ----- Original Message ----- Subject: AW: [OJB-developers] C/S JUnit tests Hi Joachim, > Hy, > > are there any JUnit tests that test the C/S-Model? As I'm doing some > refactoring in this area to allow simple a implementation of the > PersistenceBrokerServlet. Unfortunately I don't know enough > of JUnit to > write those tests myself (I know, I better have to learn it, now!). > Currently there are no special JUnit tests for the C/S mode. To test C/S mode I do the following: 0. compile everything with build.sh main 1. Switch to server mode in OJB.properties. 2. Setup test database with build.sh tests 3. startup server with server.sh 4. run all JUnit tests with build.sh junit HTH, Thomas > regards > Joachim Sauer |
|
From: Mahler T. <tho...@it...> - 2002-03-13 16:33:04
|
Hi again Ranjan, > -----Urspr=FCngliche Nachricht----- > Von: Ranjan Bagchi [mailto:ran...@fr...] > Gesendet: Mittwoch, 13. M=E4rz 2002 17:17 > An: obj...@li... > Betreff: [OJB-developers] Multiple repositories >=20 >=20 > Another question: >=20 > Is there a way to configure/use OJB so that distinct=20 > PersistenceBrokers > with different repositories can be used? =20 Yes, you can use the PersistenceBrokerFactory to create Brokers to use different repositories. =20 > OJB's getting=20 > somewhat popular, > and I'm hoping to head off a problem where two components=20 > using OJB to do > persistence end up in the same VM. I've not tested this scenario, but I don't see any problems here! cu, Thomas > Thanks again, >=20 > Ranjan >=20 >=20 > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers >=20 |
|
From: Mahler T. <tho...@it...> - 2002-03-13 16:09:55
|
Hi Joachim, > Hy, > > are there any JUnit tests that test the C/S-Model? As I'm doing some > refactoring in this area to allow simple a implementation of the > PersistenceBrokerServlet. Unfortunately I don't know enough > of JUnit to > write those tests myself (I know, I better have to learn it, now!). > Currently there are no special JUnit tests for the C/S mode. To test C/S mode I do the following: 0. compile everything with build.sh main 1. Switch to server mode in OJB.properties. 2. Setup test database with build.sh tests 3. startup server with server.sh 4. run all JUnit tests with build.sh junit HTH, Thomas > regards > Joachim Sauer > > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > |
|
From: Ranjan B. <ran...@fr...> - 2002-03-13 15:51:38
|
Another question: Is there a way to configure/use OJB so that distinct PersistenceBrokers with different repositories can be used? OJB's getting somewhat popular, and I'm hoping to head off a problem where two components using OJB to do persistence end up in the same VM. Thanks again, Ranjan |
|
From: Mahler T. <tho...@it...> - 2002-03-13 15:26:21
|
Hi again, > -----Urspr=FCngliche Nachricht----- > Von: Ranjan Bagchi [mailto:ran...@fr...] > Gesendet: Mittwoch, 13. M=E4rz 2002 16:29 > An: Mahler Thomas > Cc: obj...@li... > Betreff: Re: AW: [OJB-developers] Roadmap from OJB -> ODMG API's >=20 >=20 >=20 > Thomas, >=20 > Yes -- the 2nd option (custom collection classes) is by far=20 > the prefered > method. Is DList a good example, or should I look elsewhere? >=20 DListImpl is a good point to start as overwritten methods like = remove(...) show you what to do. BUT: DListImpl uses the ODMG transaction to register the removed Entry = for deletion. You will have to implement your own registration mechanism. And = DListImpl won't help you much here... cu, Thomas > Thanks for the quick response, >=20 > Ranjan >=20 > On Wed, 13 Mar 2002, Mahler Thomas wrote: >=20 > > Hi Ranjan, > >=20 > > > Hi -- > > >=20 > > > Perhaps this is in the docs, but I haven't seen it: I've=20 > got a fairly > > > useful set of persistent objects using the OJB API. =20 > However, deletion > > > from collections (representing a 1:n mapping) isn't getting > > > persisted. According to the FAQ I should be using the ODMG=20 > > > API instead > > > which will handle this. > > >=20 > > > (First off, is this right?) > > >=20 > >=20 > > Yes. The PersistenceBroker does not track changes to Collections.=20 > >=20 > > You can do 2 things: > > 1. Use the ODMG Collections DListImpl etc. They do track=20 > such changes > > automatically. > > Of course you have to use ODMG Transactions then. > >=20 > > 2. Implement your own mechanism that tracks changes to=20 > collections and uses > > the PersistenceBroker to persist these changes. > > (E.G. You might implement your own Collection Classes that=20 > track deletion of > > objects) > >=20 > > Maybe this second option is easier to implement as you=20 > won't have to change > > so much of your existing code. > >=20 > > HTH, > >=20 > > Thomas > >=20 > > > Has anyone done this readjustment? Any caveats? > > >=20 > > > Thanks, > > >=20 > > > Ranjan Bagchi > > >=20 > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > Objectbridge-developers mailing list > > > Obj...@li... > > >=20 > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > > >=20 > >=20 > >=20 >=20 |
|
From: Ranjan B. <ran...@fr...> - 2002-03-13 15:04:22
|
Thomas, Yes -- the 2nd option (custom collection classes) is by far the prefered method. Is DList a good example, or should I look elsewhere? Thanks for the quick response, Ranjan On Wed, 13 Mar 2002, Mahler Thomas wrote: > Hi Ranjan, > > > Hi -- > > > > Perhaps this is in the docs, but I haven't seen it: I've got a fairly > > useful set of persistent objects using the OJB API. However, deletion > > from collections (representing a 1:n mapping) isn't getting > > persisted. According to the FAQ I should be using the ODMG > > API instead > > which will handle this. > > > > (First off, is this right?) > > > > Yes. The PersistenceBroker does not track changes to Collections. > > You can do 2 things: > 1. Use the ODMG Collections DListImpl etc. They do track such changes > automatically. > Of course you have to use ODMG Transactions then. > > 2. Implement your own mechanism that tracks changes to collections and uses > the PersistenceBroker to persist these changes. > (E.G. You might implement your own Collection Classes that track deletion of > objects) > > Maybe this second option is easier to implement as you won't have to change > so much of your existing code. > > HTH, > > Thomas > > > Has anyone done this readjustment? Any caveats? > > > > Thanks, > > > > Ranjan Bagchi > > > > > > > > > > _______________________________________________ > > Objectbridge-developers mailing list > > Obj...@li... > > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > > > > |
|
From: <Joa...@tp...> - 2002-03-13 15:01:17
|
Hy, are there any JUnit tests that test the C/S-Model? As I'm doing some refactoring in this area to allow simple a implementation of the PersistenceBrokerServlet. Unfortunately I don't know enough of JUnit to write those tests myself (I know, I better have to learn it, now!). regards Joachim Sauer |
|
From: Mahler T. <tho...@it...> - 2002-03-13 14:57:53
|
Hi Ranjan, > Hi -- > > Perhaps this is in the docs, but I haven't seen it: I've got a fairly > useful set of persistent objects using the OJB API. However, deletion > from collections (representing a 1:n mapping) isn't getting > persisted. According to the FAQ I should be using the ODMG > API instead > which will handle this. > > (First off, is this right?) > Yes. The PersistenceBroker does not track changes to Collections. You can do 2 things: 1. Use the ODMG Collections DListImpl etc. They do track such changes automatically. Of course you have to use ODMG Transactions then. 2. Implement your own mechanism that tracks changes to collections and uses the PersistenceBroker to persist these changes. (E.G. You might implement your own Collection Classes that track deletion of objects) Maybe this second option is easier to implement as you won't have to change so much of your existing code. HTH, Thomas > Has anyone done this readjustment? Any caveats? > > Thanks, > > Ranjan Bagchi > > > > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > |
|
From: Ranjan B. <ran...@fr...> - 2002-03-13 14:22:53
|
Hi -- Perhaps this is in the docs, but I haven't seen it: I've got a fairly useful set of persistent objects using the OJB API. However, deletion from collections (representing a 1:n mapping) isn't getting persisted. According to the FAQ I should be using the ODMG API instead which will handle this. (First off, is this right?) Has anyone done this readjustment? Any caveats? Thanks, Ranjan Bagchi |
|
From: Georg S. <ge...@me...> - 2002-03-13 10:10:07
|
Hi,
When doing a query like
select allX from X where ...
and putting an invalid X classname a NullPointerException is thrown in
OQLQueryImpl at
this.bindIterator = this.flatten(this.query.getCriteria(), new
Vector()).iterator();
The reason is that in OQLParser at method fromClause()
try {
clazz = Class.forName(id.getText(), true,
Thread.currentThread().getContextClassLoader());
} catch (Exception e) {}
The ClassNotFoundException is simply ignored. I just put
throw new TokenStreamException(id.getText() + " is not a valid
classname");
into the catch clause, which is then propagated up to the application as a
QueryInvalidException, which for me does make sense in this case.
Regards
Georg
|
|
From: Mahler T. <tho...@it...> - 2002-03-12 14:32:16
|
Hi Fabian,
=20
I'm a bit late in responding to your mail.=20
But I'm really interested in this kind of thing, as the presentation of
results is quite readable and provides much better information than the
console based version.
=20
I'll try to integrate this target into the OJB build.xml.
=20
Do we need the optional ant targets for JUNIT to do this?
=20
thanks,
=20
Thomas
-----Urspr=FCngliche Nachricht-----
Von: Fabian B=FCttner [mailto:f_b...@ma...]
Gesendet: Dienstag, 19. Februar 2002 19:11
An: obj...@li...
Betreff: [OJB-developers] regression tests
Hello,
=20
(Currently ojb uses the java task to perform regression tests)
=20
I'm using the junit/junitreport task when testing ojb.=20
The junitreport task summarizes the junit output (format is xml) and
transforms it into html.=20
I find that the html presentation of the regression tests is much more
readable than the pure text output of the currently used textual =
TestRunner.
=20
I have attached a zip file containing an example junitreport result =
(set of
html files). Click on AllTests to expand the broker tests. There can be
multiple tests in the generated site (e.g. broker, odmg, jdo ...).=20
=20
Is there any interest in doing it this way in ojb?
=20
Below is a test target I have used:
=20
<target name=3D"junit_reports" depends=3D"main, tests">
<junit fork=3D"yes" dir=3D"${test}/ojb">
<classpath>
<pathelement path=3D"${runtime_classpath}" />
</classpath>
<formatter type=3D"xml" />
<test name=3D"test.ojb.broker.AllTests"/>
<! -- test name=3D"test.ojb.odmg.AllTests"/ -->
<! -- test name=3D"additional tests..."/ -->
</junit>
<junitreport>
<fileset dir=3D".">
<include name=3D"TEST-*.xml"/>
</fileset>
<report format=3D"frames" toDir=3D"."/>
</junitreport>
</target>
=20
Fabian B=FCttner
green@remove_no_spam.informatik.uni-bremen.de
<mailto:green@remove_no_spam.informatik.uni-bremen.de>=20
=20
|
|
From: Georg S. <ge...@me...> - 2002-03-12 13:13:47
|
Hi,
I ran into an interesting problem. It goes like this:
I have a class A which implements an interface IA. repository.xml
therefore has an extent section. A is loaded with a dynamic proxy.
I can now do OQL queries like the following without a problem:
select anyIA from IA where .....
The problem starts when I say:
select anyA from A where ....
I don't get any results back due to the following:
In RsIterator, getIdentityFromResultSet() the following happens,
return new Identity(getExtentClass(),pkValues);
getExtentClass() in the end calls the DescriptorRepository
getExtentClass() method and assigns the first available baseclass or
interface(another problem I'll come to in a minute)
in our case this is IA
in PersistenceBrokerImpl , public ManageableCollection
getCollectionByQuery(Class collectionClass, Query query, boolean lazy)
the following lines are reached
if (itemClass.isAssignableFrom(candidateClass))
{
tmpMap.add(candidate);
}
itemClass would be A in our case and candidateClass is IA and since it is
obviously not possible to cast IA onto A, the object is not added to the
result.
Another possible problem in this respect could be the fact mentioned
earlier that the method getExtentClass(Class clazz) in
DescriptorRepository just returns the first baseclass or interface it
encounters, so if a class is a member of various extents a random
baseclass or interface will be returned as first one in each run of a
program due to the fact that
Iterator iter = m_DescriptorTable.values().iterator();
ist called and since m_DescriptorTable is a Hashtable it doesn't guarantee
any special order of values returned.
Regards
Georg
|
|
From: Jakob B. <jbr...@ho...> - 2002-03-11 20:33:14
|
hi,
the report query stuff is now in the cvs.
simple field names in functions are also resolved. ie: sum(salary) will be
translated to sum(myTable.salary).
this also works for selection criteria.
jakob
----- Original Message -----
From: "Jakob Braeuchi" <jbr...@fr...>
To: <obj...@li...>
Sent: Saturday, March 09, 2002 10:26 PM
Subject: [OJB-developers] enhanced report queries
> hi,
>
> the attached zip contains some enhancements for reports (queries returning
> rows not 'real' objects):
> - define the columns to be selected (column names are properly resolved
> using the field description if available)
> - allow joins in selected columns
>
> System.out.println("\nreport (id,name,vorname,konti.saldo) with name like
> '%er'");
> crit = new Criteria();
> crit.addEqualTo("name", "%er");
> query = new QueryByCriteria(Person.class, crit);
> query.setColumns(new String[]{"id","name","vorname","konti.saldo"}); //
> define the columns
> broker.getReportQueryIteratorByQuery(query);
>
> this also allows some aggregate queries, but column names are NOT resolved
> (no field decription for 'sum(test)' ):
>
> System.out.println("\nreport (sum(test) with name like '%er'");
> crit = new Criteria();
> crit.addEqualTo("name", "%er"); // uses Like
> query = new QueryByCriteria(Person.class, crit);
> query.setColumns(new String[]{"sum(test)"}); // column name is NOT
> resolved here
> broker.getReportQueryIteratorByQuery(query);
>
>
> jakob
>
> thomas: if you find this patch useful, please let me know, and i'll check
it
> in to cvs.
>
>
>
>
|
|
From: John W. <hw...@re...> - 2002-03-11 20:32:15
|
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.
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
> >
> >
> >
> >
>
>
>
|
|
From: Thomas M. <tho...@ho...> - 2002-03-11 19:48:14
|
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
>
>
>
>
|
|
From: Thomas M. <tho...@ho...> - 2002-03-11 19:47:57
|
Hi John, John Wang wrote: > As my application needs a high performance design, I am wondering > whether it is possible to modify the classdescriptor in the runtime, to > disable the loading of unneeded fields, and for collections, don't load > the collection object's primary keys at all (the collection may contain > thousands of items), but load only when needed. Can I do it in the runtime? > Yes. The Metadata layer is completely dynamic. There is a method setClassDescriptor(...) in PersistenceBroker that allows to write modified ClassDescriptors to the DescriptorRepository. You may also use CollectionProxies and ReferenceProxies to minimize load overhead during object materialization. Just have a look at the TestCases for this features. Using proxies there is no need to change MetaData at runtime for 1:1, 1:n and n:m associations as they defer materialization of objects to the latest possible point in time (aka "lazy materialization"). To get an impression if OJB will meet your performance needs, there is a special ANT target "performance". Call build[.sh] performance to execute these tests against your target database. The tests perform mass operations 1. using OJB, 2. using native JDBC calls. These tests will give you an impression about the impact OJB has on your applications performance! (In typical Evironments about 10 - 25 % ) The code for the Jdbc based reference test contain sample code that may be helpful if a full dynamic O/R mapping is no option for certain performance critical operations. OJB may still be helpful in such cases as it allows to work cleanly with JDBC connections and PreparedStatements. (just have a look at the test cases) > > > Say that for an user, it has following categoties of info: > > 1. basic info: id, name, > > 2. extended info: home address > > 3. clob field: photo > > 4. collection: a long list of friends > > > > When retrieve a list of users, it only need to retrieve the basic info; > when view a specific user, it needs the extended info; when you want to > photo, you need to clob fields. You certainly don't want to get the > friends until you want to view a specific user, and also no need to > retrieve primary keys of friends collection, too. > > > > Is it possible to do using OJB? sure! There is also another technique that might be useful: ReportQueries. ReportQueries might be used to retrieve a list of basic info. They won't materialize full User objects! Have a look at PersistenceBroker::getReportQueryIteratorByQuery(Query) and the respective TestCases! > > > > Thanks a lot, > > John W > > > |
|
From: John W. <hw...@re...> - 2002-03-11 18:35:32
|
I am thinking that in a web application development, usually we use a
connection pool, and get a connection from there. 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?
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?
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
>
|
|
From: John W. <hw...@re...> - 2002-03-11 18:01:42
|
As my application needs a high performance design, I am wondering = whether it is possible to modify the classdescriptor in the runtime, to = disable the loading of unneeded fields, and for collections, don't load = the collection object's primary keys at all (the collection may contain = thousands of items), but load only when needed. Can I do it in the = runtime? Say that for an user, it has following categoties of info: 1. basic info: id, name,=20 2. extended info: home address 3. clob field: photo 4. collection: a long list of friends When retrieve a list of users, it only need to retrieve the basic info; = when view a specific user, it needs the extended info; when you want to = photo, you need to clob fields. You certainly don't want to get the = friends until you want to view a specific user, and also no need to = retrieve primary keys of friends collection, too. Is it possible to do using OJB? Thanks a lot, John W |
|
From: <Joa...@tp...> - 2002-03-11 17:48:01
|
Hy, I've found some time today and did a simple patch to CodeSwitcher from the hsqldb distribution (actually my patch is to the cvs-version, but it seems it is equal to the last release). The patch is very simple, but not heavily tested (mainly, 'cause it is 6:48 PM now and I should have stopped working long ago, but also 'cause I'm not yet absolutely sure which chain of events causes the error, but I assume its checkout into unix -> use codeswitcher -> checking codeswitched code into cvs -> checkout into windows (wow, long nested parentheses, I should've learned lisp)). I've mailed the hsqldb-developers and sent them the patch along with a description of the problem. It seems, according to [0], that a release candidate of 1.7.0 is about to come "real soon now", but I have no idea if my patch has any chance of beeing included or not. regards Joachim Sauer [0] http://www.geocrawler.com/archives/3/11085/2002/3/0/7989655/ (See attached file: CODESW~1.DIF) |
|
From: Mahler T. <tho...@it...> - 2002-03-11 15:40:15
|
Hi Joachim,
> Hy,
>
> finally I come to the stage where I stop flaming and start
> doing real work.
;-)
<snip task no 1> I'm going to
> contact the hsqldb-Maintainer regarding this issue and try to
> give him a
> patch for this ('though I doubt, that he will release a new
> version just
> for this patch, unless of course he has enough patches otherwise).
>
good idea!
I'm not quite sure about the HSQLDB status. They did not bring out new
releases for months !
> The other problem is, that we'd love to use the C/S-concept of of
> ObjectBridge, but have rather specific network-restrictions
> (HTTP/HTTPS at
> most). So, we'd need to wrap the PersistenceBrokerServer into
> a Servlet.
That's also a very good idea. I designed the PB Client and Server stuff in a
way to allow a simple servlet implementation.
> Basically this is no problem (from what I saw it seems that the
> functionality is seperated quite good). Obviously I'd also
> need some minor
> modifications to the PersistenceBrokerClient. Now I'd like to
> know if you'd
> prefer it if I modified those files to support both (only
> about 15-30 lines
> of changes in each of them, I guess) or if should copy them and do my
> modifications on new Classes. (or even do some refactoring,
> but I have to
> look into it, if it would even be necessary).
I think it would be cool to allow the client to talk to either TCP/IP socket
based server or to a servlet based server.
>
> One more problem also has to do with C/S: there doesn't seem
> to be any kind
> of authentification and/or encryption support in it. Both of
> them would be
> fairly easy, once they have the ability to use Servlets as the Server.
>
No, currently there is nothing of that kind implemented.
> Btw, has the C/S-concept been optimized with regards to
> bandwidth/latency?
> At the first glance it seem that it is intended to be used
> primarily in a
> LAN.
This may become a larger isssue! Currently there are no bandwidth
optimization implemented.
I'd like to use on the fly GZIP compression, but unfortunately object
serialization does not work properly with this compression :-(
I'm not very happy with the performance (and bandwith consumption) of the
C/S mode, but I currently I have no ideas how to optimize it.
Maybe a servlet based implementation may help here too.
Thanks for you offer to help !
cu,
Thomas
>
> regards
> Joachim Sauer
>
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>
|
|
From: <Joa...@tp...> - 2002-03-11 15:11:22
|
Hy,
finally I come to the stage where I stop flaming and start doing real work.
At the moment I have got two TODOs; both are non-intrusive and require no
special knowledge of the OJB-internals (thus they are perfect for me ;-).
First of all I'd like to resolve the Newline-Problem (I don't know if
anyone else runs into it, but i'd like to fix it nevertheless). I've taken
a closer look at the script-tool in the hsqldb-Repository and it seems that
the problem is that it uses windows-newlines hardcoded (instead of
system-dependent newlines). This is no problem for java itself (it
interprets all legal newlines on all platforms, even mixed) but when you
check it into CVS from a unix platform, but using windows-newlines, CVS
assumes that you allready give it unix-newlines, and thus completely f*cks
up the newlines when you check it out again on windows. I'm going to
contact the hsqldb-Maintainer regarding this issue and try to give him a
patch for this ('though I doubt, that he will release a new version just
for this patch, unless of course he has enough patches otherwise).
The other problem is, that we'd love to use the C/S-concept of of
ObjectBridge, but have rather specific network-restrictions (HTTP/HTTPS at
most). So, we'd need to wrap the PersistenceBrokerServer into a Servlet.
Basically this is no problem (from what I saw it seems that the
functionality is seperated quite good). Obviously I'd also need some minor
modifications to the PersistenceBrokerClient. Now I'd like to know if you'd
prefer it if I modified those files to support both (only about 15-30 lines
of changes in each of them, I guess) or if should copy them and do my
modifications on new Classes. (or even do some refactoring, but I have to
look into it, if it would even be necessary).
One more problem also has to do with C/S: there doesn't seem to be any kind
of authentification and/or encryption support in it. Both of them would be
fairly easy, once they have the ability to use Servlets as the Server.
Btw, has the C/S-concept been optimized with regards to bandwidth/latency?
At the first glance it seem that it is intended to be used primarily in a
LAN.
regards
Joachim Sauer
|
|
From: Mahler T. <tho...@it...> - 2002-03-11 12:08:38
|
Hi Bill, > -------- Original Message -------- > Subject: RE: Loading the repository > Date: Sat, 9 Mar 2002 21:23:58 -0500 > From: "Bill Robertson" <bi...@te...> > To: "Thomas Mahler" <tho...@ho...> > > Hello Thomas, > > Now that you've had a few days to look at my previous mail, > do you have any thoughts about what's going on? > In the last weeks there have been several complaints (or questions) about using OJB within Tomcat. I started to setup a Tomcat environment over the weekend to write a little demo Servlet using OJB. I will publish my findings and propose some hints how the mentioned problems can be solved. I hope to get things finished this week ! thanks for your patience > Thanks, > Bill > > -----Original Message----- > From: Thomas Mahler [mailto:tho...@ho...] > Sent: Monday, March 04, 2002 5:17 AM > To: Bill Robertson > Subject: Re: Loading the repository > > > Hi Bill, > > > Bill Robertson wrote: > > > Hello, > > > > I made a change to ojb to allow it to load a repository > > file from the classpath (i.e. getClass().getResource()) as > > an alternative. I will sheepishly admit that I didn't > > understand what the existing method does. > > > > > The current solution is supposed to also load stuff from the > classpath. > It does look that strange as this is the J2EE compliant way > of obtaining > a classloader! > > Why did you think it was necessary to implement your change? > Did loading > OJB.properties and repositories from the classpath not > work for you? > > > > I added methods in the PersistenceBrokerFactory and > > DescriptorFactory that take a boolean. If the boolean is > > true it loads the resource URL in the method described > > above. If it's false it loads it the other way. I then > > changed the exisiting methods to call the new method with a > > default parameter of "false" so as not to change existing > > behavior. > > > > If you are interested in this simple change, please let me > > know. I would be happy to send you the files. > > > Yes, you may send me your file, maybe I understand the > difference when I > see the code. > > thanks, > > Thomas > > > > > Thanks, > > Bill Robertson > > > > > > > > > > > > > > > > |
9 messages has been excluded from this view by a project administrator.
