Importing a repository on ORACLE 10g

Classic Servoy
1

When importing a repository on Oracle 10g, I notice, that once in a while the import takes very looooong. On other days it is completely normal. When I look at the stack trace, I see this towards the end. The query times increase all the time and “one day” it gets done:

Updating children
Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 30 ms for 0 objects (query took 30 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 110 ms for 0 objects (query took 110 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]
Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]
Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 280 ms for 0 objects (query took 280 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 580 ms for 0 objects (query took 580 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 741 ms for 0 objects (query took 741 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]
Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 2093 ms for 0 objects (query took 2093 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 2253 ms for 0 objects (query took 2253 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 2714 ms for 0 objects (query took 2714 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 2794 ms for 0 objects (query took 2794 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 3015 ms for 0 objects (query took 3015 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 3114 ms for 0 objects (query took 3114 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]
Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 3214 ms for 0 objects (query took 3214 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]
Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]
Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]
Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]
Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 4807 ms for 0 objects (query took 4807 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]
Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]
Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]
Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]
Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 6339 ms for 0 objects (query took 6339 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]
Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]
Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 6739 ms for 0 objects (query took 6729 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]
Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 7161 ms for 0 objects (query took 7161 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]
Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 7130 ms for 0 objects (query took 7130 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]
Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 7421 ms for 0 objects (query took 7421 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 7431 ms for 0 objects (query took 7431 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]
Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 8022 ms for 0 objects (query took 8022 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]
Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]
Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 8492 ms for 0 objects (query took 8492 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]
Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 8603 ms for 0 objects (query took 8603 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]
Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]
Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 9213 ms for 0 objects (query took 9213 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]
Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 9294 ms for 0 objects (query took 9294 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 9594 ms for 0 objects (query took 9594 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 9653 ms for 0 objects (query took 9653 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 10024 ms for 0 objects (query took 10024 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 10155 ms for 0 objects (query took 10155 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 10485 ms for 0 objects (query took 10475 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 10355 ms for 0 objects (query took 10355 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]
Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 10896 ms for 0 objects (query took 10896 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

loadObjects duration 10956 ms for 0 objects (query took 10956 ms)

Solution ‘mod_kundenmodul’ read only connection requested by thread TaskExecuter[3]

Is this normal?

Thanks
Patrick

2

what does the import say on another database? (exactly the same module)

3

I have sent an email to Sebastiaan (he didn’t answer yet) with this text:

I am trying to import several modules and a solution into an emtpy
repository that sits on an ORACLE 10g system. I can import one
solution/module fine. When I try to import another module, I see in the
stack trace everything going normal until a point where it says

“Updating children”

after that it goes like this:

Solution ‘mod_toolkit’ read only connection requested by thread
TaskExecuter[0]

loadObjects duration 110 ms for 0 objects (query took 110 ms)

Solution ‘mod_toolkit’ read only connection requested by thread
TaskExecuter[0]
Solution ‘mod_toolkit’ read only connection requested by thread
TaskExecuter[0]
Solution ‘mod_toolkit’ read only connection requested by thread
TaskExecuter[0]
Solution ‘mod_toolkit’ read only connection requested by thread
TaskExecuter[0]
Solution ‘mod_toolkit’ read only connection requested by thread
TaskExecuter[0]

loadObjects duration 3435 ms for 0 objects (query took 3435 ms)

Solution ‘mod_toolkit’ read only connection requested by thread
TaskExecuter[0]

loadObjects duration 6690 ms for 0 objects (query took 6690 ms)

Solution ‘mod_toolkit’ read only connection requested by thread
TaskExecuter[0]

loadObjects duration 7811 ms for 0 objects (query took 7811 ms)

Solution ‘mod_toolkit’ read only connection requested by thread
TaskExecuter[0]

loadObjects duration 8622 ms for 0 objects (query took 8622 ms)

Solution ‘mod_toolkit’ read only connection requested by thread
TaskExecuter[0]

loadObjects duration 16453 ms for 0 objects (query took 16453 ms)

Solution ‘mod_toolkit’ read only connection requested by thread
TaskExecuter[0]
Solution ‘mod_toolkit’ read only connection requested by thread
TaskExecuter[0]
Solution ‘mod_toolkit’ read only connection requested by thread
TaskExecuter[0]

loadObjects duration 13980 ms for 0 objects (query took 13980 ms)

Solution ‘mod_toolkit’ read only connection requested by thread
TaskExecuter[0]
Solution ‘mod_toolkit’ read only connection requested by thread
TaskExecuter[0]

loadObjects duration 16063 ms for 0 objects (query took 16063 ms)

Solution ‘mod_toolkit’ read only connection requested by thread
TaskExecuter[0]
Solution ‘mod_toolkit’ read only connection requested by thread
TaskExecuter[0]

loadObjects duration 16835 ms for 0 objects (query took 16835 ms)

Solution ‘mod_toolkit’ read only connection requested by thread
TaskExecuter[0]
Solution ‘mod_toolkit’ read only connection requested by thread
TaskExecuter[0]

This seems to go on forever. It is always this point and at the time I
look at this I see a Lock on Oracle from two sessions that comes from my
machine. It also seems that the query times get longer and longer and
longer.

Oracle also complained about this statement, saying that it takes too
long and should be otpimized:

SELECT cs.object_type_id, r.element_id, cs.property_name,
ep.property_value, r.revision, cs.type_id
FROM servoy_releases r, servoy_elements e,
servoy_element_properties ep, servoy_content_spec cs
WHERE r.solution_id = :1
AND r.release_number = :2
AND r.element_id = e.element_id
AND r.revision = e.revision
AND e.object_type_id = cs.object_type_id
AND e.parent_element_id = :3
AND e.element_id = ep.element_id
AND ep.content_id = cs.content_id
AND r.revision = ep.revision
ORDER BY cs.object_type_id, r.element_id, cs.content_id,
ep.sequence

I have managed to import several modules, but then couldn’t import the
solution. When I tried to import the solution first, there was no
problem, but then I couldn’t load the first little module.

We have tried to import into a different schema to a repository, that already had older versions of the repository. There it worked!? This might be an Oracle issue (schema related? access rights? ??), but if that is the case, it’d be nice if Servoy could warn about problems or something. I wasted almost one day when trying to import ten modules…

4

I usually work on MS SQL, where this problem never occurs.

5

Hello,

this really doesn’t work! I have tried almost everything (different users, different access rights, using a schema, using no schema) etc. I seem to be able to import smaller modules into a blank repository, but nothing “bigger”. It always gets stuck at this point after “Updating children”. What also might be noteworthy is that the CPU of the Oracle server is up to 100% while Servoy tries to import!?

I am using the classes12.jar as a driver (maybe that’s the problem?), that I found here: http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/htdocs/jdbc101020.html

Is there any help?

Thanks
Patrick

6

I found it (I think): you need more than classe12.jar. It looks like for some reason Servoy uses something for repository import that is only avalailable in a “ocrs12.jar” and titled as

classes that implement the javax.sql.rowset interfaces, like CachedRowSet and WebRowSet. To be used with JDK 1.2, 1.3, and 1.4.

So for anyone having to use Oracle 10g, you also need this one :D

7

Patrick,

We’re doing stuff on Oracle as well.

As of Oracle 9, they changed the naming logic for drivers. The Java drivers are now named:

ojdbcXX.jar

where XX stands for the Java version.

so, if you are working on Java 1.4.x, use ojdbc14.jar.

Classes12 is an old driver, designed for java 1.2

Just my 5 cents…

Paul

8

We’re doing stuff on Oracle as well.

I feel with you…

Thanks for your help. I have the impression that it does work OK now. I think these people are the only crazy guys to use 10g…

9

how did you find out that you need more then just classes12.zip? As far as i know, i will ask around, we really aren’t using anything else or special. (like cached rowset)

10

Just found out that there are different versions of the classes12.jar driver for Oracle are around.

Allthough Oracle says use ojdbc14.jar with Oracle 9x and Java 1.4.x, Servoy likes using the latest classes12.jar a lot better…

We had some ClassCast issue with the old version of classes12.jar ANd with ojdbc14.jar, but now, with the latest version of classes12.jar, no problems at all…

Paul

11

and the really latest ojdbc14.jar still has that classcast?
Please report that to oracle! Because then the fixes that are in classes12.jar aren’t there yet in the 1.4 stream.

12

how did you find out that you need more then just classes12.zip? As far as i know, i will ask around, we really aren’t using anything else or special. (like cached rowset)

Since I wasn’t able to import anything into ORACLE I just tried and downloaded everything that sounded like it could be needed. After I dropped that into the drivers folder, I could import everything just fine?!

13

didn’t you just upgraded to the latest classes12.jar? This one does fix a few things.

14

I am a little confused on the driver issue. What is the “latest” classes12.jar? On the Oracle web site I see only one (see link above), in the manifest it says it’s a build from January 2004. I don’t see any other classes12.jar. Right now I am using the ojdbc14, since Paul said above (and so does the Oracle download page), that this is to use for Java 1.4 and so on.

So what driver should we use and where can it be downloaded?

Thanks
Patrick

P.S.: My importing problem didn’t seem to change whatever driver I used. This ocrs12.jar seemed to solve it, though…

15

OK, to sum it up:

I (re)downloaded the latest ojdbc14.jar from http://www.oracle.com/technology/softwa … c9201.html

Where before my ClassCast issue still appeared with ojdbc14.jar, I tested it now again and it works fine. :shock: The manifest of this Jar says:

Manifest-Version: 1.0
Specification-Title: “Oracle JDBC driver classes for use with JDK1.4”
Specification-Version: “Oracle JDBC Driver version - 9.0.2.0.0”
Specification-Vendor: “Oracle Corporation” .
Implementation-Title: “ojdbc14.jar”
Implementation-Version: “Oracle JDBC Driver version - 9.0.2.0.0”
Implementation-Vendor: “Oracle Corporation”
Implementation-Time: “Tue Apr 6 01:10:57 2004”

According to the Oracle website, this ojdbc14.jar is THE driver to use for Oracle 9 and upwards in combination with Java 1.4

The latest version of the Classes12.zip driver has the following info in the manifest:

Manifest-Version: 1.0
Specification-Title: “Oracle JDBC driver classes for use with JDK1.2 and JDK1.3”
Specification-Version: “Oracle JDBC Driver version - 9.0.2.0.0”
Specification-Vendor: “Oracle Corporation” .
Implementation-Title: “classes12 archives”
Implementation-Version: “Oracle JDBC Driver version - 9.0.2.0.0”
Implementation-Vendor: “Oracle Corporation”
Implementation-Time: “Tue Apr 6 01:03:07 2004”

As per the manifest: This driver is for use with Oracle 9 and upwards in combination with Java 1.2 and 1.3

Regards,

Paul