# Using Hangfire.Pro.Redis with Dragonfly **URL:** \ **Category:** bug?\ **Tags:** redis, aspnetcore\ **Created:** [April 8, 2024, 11:38pm UTC](https://discuss.hangfire.io/t/using-hangfire-pro-redis-with-dragonfly/10602 "2024-04-08T23:38:00Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Joel](https://dub1.discourse-cdn.com/flex017/user_avatar/discuss.hangfire.io/joel/32/3049_2.png) [@Joel](https://discuss.hangfire.io/u/Joel)\ **Post date:** [April 8, 2024, 11:38pm UTC](https://discuss.hangfire.io/t/using-hangfire-pro-redis-with-dragonfly/10602/1 "2024-04-08T23:38:00Z")
After the recent Redis drama we are exploring other options, such as [https://www.dragonflydb.io/](https://www.dragonflydb.io/), which claims to be a drop-in Redis replacement. It seems to function fine for our other caching needs but when using it with Hangfire and doing `recurringJobManager.AddOrUpdate()` a `StackExchange.Redis.RedisServerException` is thrown with message `ERR EXEC without MULTI`. This suggests that some operations or perhaps some _order_ of operations is accepted by Redis and not by Dragonfly. Tested with Hangfire.Pro.Redis 3.0.7 and 3.1.0-beta4. Any ideas on what this could be / will it be investigated to officially make this Redis library more compatible with replacements, perhaps even with the new [ValKey](https://github.com/valkey-io/valkey)? ---
**Author:** ![odinserj](https://dub1.discourse-cdn.com/flex017/user_avatar/discuss.hangfire.io/odinserj/32/648_2.png) [@odinserj](https://discuss.hangfire.io/u/odinserj)\ **Post date:** [April 9, 2024, 9:14am UTC](https://discuss.hangfire.io/t/using-hangfire-pro-redis-with-dragonfly/10602/2 "2024-04-09T09:14:17Z")
StackExchange.Redis, either original or our forked one, issue a `SELECT` command after each `EVAL`/`EVALSHA` command in a transaction. And it looks like Dragonfly doesn’t like this kind of database switching, because of its (I suppose) concurrency implementation that doesn’t support (I suppose) commands from different databases inside a single transaction. So this is a behavior of a client, so I just made a [commit to our fork of SE.Redis](https://github.com/HangfireIO/StackExchange.Redis/commit/065e6ee734a8db54584c17da88711bb7769220f5) to change things and send the `SELECT` command after calling `EXEC` only, e.g. after executing the entire transaction. This will also prevent other threads of an unexpected database change in a LUA script, but not in the same transaction – I believe transaction’'s command set is a something that can be controlled by a developer, so we shouldn’t overly protect against such a behavior. As for the Dragonfly, I don’t believe we will support it in the near future officially, but at least tests will work against it after some tuning described in [BullMQ | Dragonfly (dragonflydb.io)](https://www.dragonflydb.io/docs/integrations/bullmq#tldr) (steps with `allow-undeclared-keys` and `lock_on_hashtags` are the same). Each storage, especially the young one, might contain its own set of bugs related to consistency and concurrency, and it’s not reasonable for us to deep dive into the implementation of each of them when there are troubles. ---
**Author:** ![odinserj](https://dub1.discourse-cdn.com/flex017/user_avatar/discuss.hangfire.io/odinserj/32/648_2.png) [@odinserj](https://discuss.hangfire.io/u/odinserj)\ **Post date:** [April 9, 2024, 9:48am UTC](https://discuss.hangfire.io/t/using-hangfire-pro-redis-with-dragonfly/10602/3 "2024-04-09T09:48:53Z")
Hm, tests fail with the ‘Multiple databases inside a transaction are not currently supported’ error, but only on the build server, only on Windows and can’t reproduce this problem locally. Looks like client implementation relies on `SELECT` commands inside a transaction, so let’s wait for support of Dragonfly and `EVAL` commands from the original StackExchange.Redis first, since this is a non-easy fix with possible race conditions.