1Z0-102 · Question #104
Which four tasks are required to use database persistence for JMS messages?
The correct answer is A. Assign a data source to a JDBC store. C. Assign a JDBC store to a JMS server. D. Create a JDBC data source. F. Create a JDBC store. See the full explanation below for the reasoning.
Question
Which four tasks are required to use database persistence for JMS messages?
Options
- AAssign a data source to a JDBC store.
- BConfigure a data source's delivery mode.
- CAssign a JDBC store to a JMS server.
- DCreate a JDBC data source.
- EDisable a server's file store.
- FCreate a JDBC store.
How the community answered
(30 responses)- A77% (23)
- B17% (5)
- E7% (2)
Community Discussion
8The group landed on A, C, D, and F, and I think that is the right call. The logic follows a clear chain: you first create a JDBC data source (D) and a JDBC store (F), then you connect the two by assigning the data source to the JDBC store (A), and finally you assign that JDBC store to the JMS server (C) so messages actually get persisted there. B trips people up because delivery mode is a message-level JMS property, not something you configure on the data source itself, and E is a distractor because you never need to explicitly disable a file store, you just stop using it by pointing the JMS server at the JDBC store instead. Does anyone in the group remember seeing a twist on this in practice tests where they swapped the order of A and C to confuse you, or was that a different objective? Would love to hear if anyone has a different take on why B or E might have seemed tempting.
The swap trap you're remembering is real, and the reason it works on people is that assigning the data source to the store feels like the last step because it sounds like a connection, but the store has to exist and be pointed at the JMS server before that assignment has anywhere to land.
Saw this word for word, crossed out B and E immediately, four left standing.
A, C, D, F is correct and the sequence tells you exactly why. You build the chain from the bottom up: create the JDBC data source, create the JDBC store, link the data source to the JDBC store, then assign that store to the JMS server. Each step depends on the previous one, so if the exam gives you a scenario question about a broken persistence setup, check whether any link in that chain is missing. B is a trap because delivery mode is a message-level or producer-level setting, not something you configure on the data source itself. E is also out because you never have to disable the file store to enable JDBC persistence, you just stop using it by pointing the JMS server at the JDBC store instead.
Good catch on E, though worth adding that if you leave an old file store configured and assigned elsewhere it can cause confusion during troubleshooting, so cleaning it up after the switch is a habit worth building.
The four are D, F, A, C, in that dependency order: you create the JDBC data source first, then create the JDBC store, then wire the data source into that store, then assign the store to your JMS server, and that chain is what actually enables database-backed persistence. B trips people up because "delivery mode" sounds JMS-adjacent, but delivery mode is a producer-level or destination-level setting, not something you configure on the data source itself. E is the sneakiest distractor, because yes, WebLogic defaults to a file store, but you do not have to disable it to activate your JDBC store, you simply assign the JDBC store to the JMS server and that assignment takes precedence. The mnemonic I give my students is "Data, Store, Link, Assign" covering D-F-A-C, four steps, one pipeline.
I keep landing on E as one of the four because if the server's default file store is still active, there is nothing forcing JMS to route through the JDBC store you just configured, so disabling it seems like the step that actually commits the system to database persistence rather than letting it silently fall back.
Grace, the logic is sound on its surface but the blueprint tests a different constraint: once you assign the JDBC store directly to the JMS server, that server is already bound to it, so there is no silent fallback to the file store for those JMS resources, which means disabling the default file store is both unnecessary and potentially harmful to other services (transaction logs, for instance) that legitimately depend on it. A, C, D, and F cover the actual commit path, which is creating the store, targeting it, assigning it to the JMS server, and activating the configuration, without touching the file store at all.