we would like to use hangfire to automate the management of our background tasks. Our software supports both SQL Server and Oracle. I’ve seen that you do not support Oracle at the moment. I would like to know if you expect to support it in future versions?
I checkout your code and i saw that you have a specific implementation for SQL Server (hangefire.SqlServer project) with a lot of specific (hard coded) SQL queries. I saw also that these queries are optimized with Hints.
Unfortunately, you do not have any interface to implement new database storage easily. From what I’ve seen, the fastest way to support Oracle is to duplicate the Hangfire.SqlServer project (Hangfire.Oracle) and review all SQL queries to make them compatible with Oracle. But this is a bad solution because we will have a bench of duplicated code and any modification will be costed twice because we should take in account the two projects (sql server and oracle).
So I would like to know if you are open to include in your project a new implementation based on Entity framework (Hangfire.EntityFramework) which will be made obviously using Entity framework to support several types of database easily (Oracle). This version will not necessarily be optimized for SQL Server but it will allow those who use other type of database to use hangFire easily. For those who want to use the optimized version, they can still use Hangfire.SqlServer.
If you are okey with this solution, we will develope it and create a pull request to integrate it in the Hangfire project.
Hi @MYoucef! Unfortunately currently it’s very hard to write your own implementation of a storage – there are a lot of data structures, and a lot of operations for them. Those operations are based on undocumented (in Hangfire itself) features that databases provide. And I’ve spent enormous amount of time trying to figure out what they are, and the details deserve a special blog post I’m planning to write sooner or later.
The thing is that it’s relatively simple to write a storage that works with the one feature set, but doesn’t work in general, for advanced features, etc. In short, strict serializability (serializability + linearizability) is required for Hangfire’s transactions. They could be relaxed in this or that way for every data structure, but there are a lot of details.
Currently you can’t implement a job storage using EntityFramework or any other ORM: there are a lot of complex queries that are different for each storage. I’ve figured out how to reduce the number of required entities and operations. And looks like the new format could be implemented in generic way for RDBMS’ using ORMs, but I need to ensure it’s complete and then decide what to do with backward compatibility – I don’t expect that people just drop all of their jobs and move to the new version.
Having a storage based on the file system could be a solution of this RDBM dependency. I mean that we can imagine a simple file system storage to handle the basic operations of Hangfile.
obviously, we cannot support all complex operations handled by Hangfire based on RDBM. But, this solution is frequent and easy use case that help developers to integrate Hangfire in their software.
Add concurrency (because Hangfire is about concurrency) and durability to those files, and you’ll get a fully-featured database at least with two-phase locking, isolation levels and transaction log. For simpler cases there are other products with no persistence at all, or based on message queues.
In our side, we think that we can start working with the current version of Hangfire to manage our background tasks under SQL Server.
However, as we have strong client constraints to support Oracle. we need more information about your project concerning the new format that could be implemented in generic way for RDBMS’ using ORMs.
Could you give us an idea about the time frame of this project. This will help us to plan our developments and communicate it to our clients.
I noticed that your project on GitHub seems to no longer be actively maintained, so I forked it to keep it updated. If you’re open to collaboration, I’d love to join forces to help keep this Oracle implementation running smoothly.