-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JdbcRepository doesn't override getJob, jobExists, getJobNames #545
Comments
FWIW: my current workaround is to load all jobs from |
@Xiphoseer Thanks for raising this! I'll arrange my time to check this. |
I guess this issue is effectively a duplicate of JBERET-66 |
I want to elaborate on the motivation a bit: Ultimately, the case where I encountered this was with
What happens though is that JBeret proxies this method to jsr352/jberet-core/src/main/java/org/jberet/operations/AbstractJobOperator.java Lines 171 to 173 in c7daf81
which ends up being implemented only by jsr352/jberet-core/src/main/java/org/jberet/repository/AbstractRepository.java Lines 74 to 81 in c7daf81
That implementation is somewhat reasonable for a generic |
I plan to do a major beta release of JBeret today or tomorrow to include several major jakarta API upgrades. After the release is done I'll go on working on this(and maybe include the work into Final release). |
Currently,
getJob
,jobExists
andgetJobNames
don't override the use of theConcurrentMap jobs
inAbstractRepository
. That means that in a multi-instance configuration, where multiple applications share the same database, only those that have at least one job started locally will be able to see that jobName.From my POV:
getJobNames
should do aSELECT DISTINCT
on the job_instances tablejobExists
should do aSELECT ... WHERE JOBNAME = ?
getJob
should ideally triggerArchiveXmlLoader.loadJobXml
with theJobXmlResolver
if the jobName is unknown but I guess that isn't available by default.The text was updated successfully, but these errors were encountered: