Anonymous wrote:Hi, I'm posting anonymously because I'm having a lot of trouble logging in right now. I even made a new account, quit my browser, and then tried logging in, and had no luck. Also, your "change password" component seems to ask for the user's e-mail address once the notification link is clicked... shouldn't that be predetermined by the link the user clicks in the notification e-mail?
One question I had was whether you're conducting actions that require getting a new ID from a sequence and using it in INSERT statements as one transaction. Our application servers are load balanced, so we're in need of software that's transaction-safe. Is JForum going to be written in a manner that takes into consideration that multiple implementations will be accessing the same database?
I'll likely have other questions as I finish up translating things for DB2 and begin testing. I'm planning on conducting this stuff alongside other projects. My department is hoping that this goes well, since we're in need of a decent Java-based forum package, and upgrading our Jive license so it will work with our load balanced application servers is cost prohibitive.
marc wrote:as the anonyomous user said it should be handled with database transactions. Synchronization only helps for a single jvm, in a cluster the database engine has to synchronize db access.
I think it will require some refactoring to move the mysql db stuff from the generic sql models in the mysql package.
I am not a mysql user, but as far as I know the driver will throw an exception if a transaction is started.
Wouldn't it make sense to use an open source cache solution like oscache or jcache ?
These cache solutions already offer a lot of options like clustering or timeouts.
marc wrote:A time out to refresh the cache from the db every minute or so should be sufficient for most installations.
Rafael Steil wrote:
hm, right. But, using the same logic, to have jforum running on multiple machines without any problem, other pieces of code should be refactored as well.
Anonymous wrote: I see a configuration option called cache.dir, but it doesn't seem to do anything. If there is no cache in jforum it shouldn't be too difficult to make it ready for clustering.
As for the avatar upload I think enterprise users are likely to disable it anyhow, and if someone really needs it, they can put the avatars on shared disk or they can add an rsync call in the upload method.
mdellabitta wrote:Ahhh... able to login now. Feels so much better!
Would an option to disable caching be feasible as a stopgap measure? Or would that negate the performance gains from clustering?
marc wrote:I would also like to have an option to disable the cache. A well tuned database can be incredibly fast.
Rafael Steil wrote: The problem is that I personally don't have too much experience with this.. You guys do?
Rafael Steil wrote:Not so fast as reading directly from the RAM ;)
I happen to be in the c-jdbc (clustered jdbc) team. However, I do not have experience with any of the cache projects I have mentioned above.
I didn't look at the jforum cache, but are you sure the cache will not run out of memory for a big forum ? It is pretty hard to write a bullet-proof cache, and I think it is outside of the scope of a forum software.