[jira] [Commented] (JUDDI-89) JDBC Datastore performance improvements

["Kurt T Stam (JIRA)" <ju...@ws.apache.org>]

    [ https://issues.apache.org/jira/browse/JUDDI-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048723#comment-13048723 ] 

Kurt T Stam commented on JUDDI-89:
----------------------------------

Unfortunately it looks like our code has changed too much for the patch to be useful any longer. However we issue still exist in the current codebase and it is time to address it as other users have run into the same issue.  We should look into splitting the IN clause up into multiple sections like:

bla_id in (2,3,5,6,12,19)

to 

bla_id in (2,3)
or
bla_id in (5,6)
or
bla_id in (12,19)

Also, instead of IN you can use = ANY, or = SOME, or EXISTS.
It could also increase performance of the query....

So we need to come up with some good test case and then go after this.

--Kurt

> JDBC Datastore performance improvements
> ---------------------------------------
>
>                 Key: JUDDI-89
>                 URL: https://issues.apache.org/jira/browse/JUDDI-89
>             Project: jUDDI
>          Issue Type: Improvement
>    Affects Versions: 0.9rc4
>         Environment: Oracle
>            Reporter: Rémi Flament
>            Assignee: Tom Cunningham
>             Fix For: 3.1.1
>
>         Attachments: juddi.patch, juddi3.patch, patch2.patch
>
>
> Hi,
> Please find a *huge* patch attached.
> We have used Juddi with more than an hundred business services and we had some issues. This patch correct these issues :
> - Juddi was *very* slow with more than 1000 business services.
> - Oracle cannot handle more than 1000 elements in SQL "IN" request, so Juddi crashed when a business entity contained more than 1000 services.
> For the "IN" problem we added a method in util/Config which gives the maximum element the db can handle in IN requests.
> For the performance problem we had to rewrite a lot of the JDBC datastore. Basically the thing is to avoid to do too much sql requests by grouping them. As an example instead of the method fetchService() we use the method fetchServices(), etc.
> Thanks to these corrections we had great performance improvement : the getbusinessdetail used to take more than 40 seconds on big business entity, now it takes about 6 seconds.
> This patch applies to v0.9rc4.
> Regards,
> Rémi Flament.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira