Sahina Bose has posted comments on this change. Change subject: engine: DB persistent quartz scheduler ......................................................................
Patch Set 4: (2 comments) @ Liran - Why do we need to have both memory and DB? If we have DB - why not just move everything to the DB? The existing job scheduling require re-architecting to move to the DB persistence. These jobs assume that they will be scheduled when the engine starts up and the in-memory job store works well for this purpose. The DB job store would be useful for jobs that are scheduled by the user and not the engine. @Moti - 1. How would the management of jobs will be executed ? Would a job-name be preserved per each entity ? or any other logic to associate the job which is scheduled for a certain entity ? Yes, the class that schedules these jobs would need to uniquely identify these job names so that these can be rescheduled/deleted etc. 2. What would be the jobs lifecycle ? will you have to introduce a logic to remove those jobs once aren't required any more ? Or to digest the current schedule jobs into a presentable view entities for the user ? Again, this would be the responsibility of the consumer class. For instance, when GlusterSnapshot uses this infra, it will maintain a list of all the snapshot scheduling jobs. We could maybe provide a view to see a master list, if required? 3. How would we verify that the quartz tables are properly managed and upgrade of quartz version will be backward compatible ? IMO since the quartz tables are exposed as DAOs and aren't managed by ovirt, we should have some system test, kind of e2e (install / upgrade / and actual usage of the those tables). Good point, I will add a test for this http://gerrit.ovirt.org/#/c/36297/4/packaging/services/ovirt-engine/ovirt-engine.xml.in File packaging/services/ovirt-engine/ovirt-engine.xml.in: Line 162: <check-valid-connection-sql>select 1</check-valid-connection-sql> Line 163: </validation> Line 164: </datasource> Line 165: Line 166: <datasource jndi-name="java:/ENGINEDataSourceNoJTA" pool-name="ENGINEDataSourceNoTx" enabled="true" use-ccm="false" jta="false"> > Why do we want a non-JTA data source? This could lead to troubles... While using the Quartz JobStoreCMT, the transactions are managed by the calling application..in this case ovirt engine. However Quartz also requires a datasource where the connections do not take part in global transactions - quartz can directly call commit and rollback on this connection - this is the reason for the non-JTA data source. Line 167: <connection-url><![CDATA[$getstring('ENGINE_DB_URL')]]></connection-url> Line 168: <driver>postgresql</driver> Line 169: <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation> Line 170: <pool> Line 168: <driver>postgresql</driver> Line 169: <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation> Line 170: <pool> Line 171: <min-pool-size>$getinteger('ENGINE_DB_MIN_CONNECTIONS')</min-pool-size> Line 172: <max-pool-size>$getinteger('ENGINE_DB_MAX_CONNECTIONS')</max-pool-size> > Please do - these are very high numbers in performance environments Ok Line 173: <prefill>true</prefill> Line 174: </pool> Line 175: <security> Line 176: <user-name><![CDATA[$getstring('ENGINE_DB_USER')]]></user-name> -- To view, visit http://gerrit.ovirt.org/36297 To unsubscribe, visit http://gerrit.ovirt.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I9a34dac95999cb6b3721d201c116fb5f6089bb61 Gerrit-PatchSet: 4 Gerrit-Project: ovirt-engine Gerrit-Branch: master Gerrit-Owner: Sahina Bose <sab...@redhat.com> Gerrit-Reviewer: Eli Mesika <emes...@redhat.com> Gerrit-Reviewer: Liran Zelkha <lzel...@redhat.com> Gerrit-Reviewer: Moti Asayag <masa...@redhat.com> Gerrit-Reviewer: Oved Ourfali <oourf...@redhat.com> Gerrit-Reviewer: Sahina Bose <sab...@redhat.com> Gerrit-Reviewer: Shubhendu Tripathi <shtri...@redhat.com> Gerrit-Reviewer: Yair Zaslavsky <yzasl...@redhat.com> Gerrit-Reviewer: anmolbabu <anb...@redhat.com> Gerrit-Reviewer: automat...@ovirt.org Gerrit-Reviewer: oVirt Jenkins CI Server Gerrit-HasComments: Yes _______________________________________________ Engine-patches mailing list Engine-patches@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-patches
