[
https://issues.apache.org/jira/browse/JUDDI-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kurt T Stam closed JUDDI-89.
----------------------------
Resolution: Fixed
Assignee: Kurt T Stam (was: Tom Cunningham)
This is now fixed (with the fix applied as part of JUDDI-569)
> 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: Kurt T Stam
> Fix For: 3.1.5
>
> Attachments: juddi3.patch, juddi.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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
