Skip to content
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

Prevent calling UpdateTimesStampsCache for non cached entites #2129

Closed
gokhanabatay opened this issue Apr 15, 2019 · 4 comments · May be fixed by #2130
Closed

Prevent calling UpdateTimesStampsCache for non cached entites #2129

gokhanabatay opened this issue Apr 15, 2019 · 4 comments · May be fixed by #2130

Comments

@gokhanabatay
Copy link
Contributor

gokhanabatay commented Apr 15, 2019

When query cache enabled, I realized that we are storing updatetimestampscache for non cached entities.
Is this really necessary in our scenario we use query cache for just Cache.ReadWrite or Cache.Readonly or Cache.NonstrictReadWrite entities, not non cached entities.

We need high performance to do that we need to decrease Sync. and locking for dml/select operations, its locks all threads in same application its too much cost for per operation.

I think that this needs to be configurable(Store all entities updatetimestampscache or just cacheable entities) or we give us a way to implement our UpdateTimestampsCache, because its readonly?

Action Queue can be check? executable.PropertySpaces && execuatble.Persister.Cache != null

                 private void RegisterCleanupActions(IExecutable executable)
		{
			if (executable is IAsyncExecutable asyncExecutable)
			{
				RegisterProcess(asyncExecutable.BeforeTransactionCompletionProcess);
				RegisterProcess(asyncExecutable.AfterTransactionCompletionProcess);
			}
			else
			{
#pragma warning disable 618,619
				RegisterProcess(executable.BeforeTransactionCompletionProcess);
				RegisterProcess(executable.AfterTransactionCompletionProcess);
#pragma warning restore 618,619
			}
			if (executable.PropertySpaces != null)
			{
				executedSpaces.UnionWith(executable.PropertySpaces);
			}
		}
@gokhanabatay
Copy link
Contributor Author

Thank you quick reply @hazzik but i think this is not Trivial issue, because when second level cache enabled there is huge performance fall down test could show this.

Summary;
ReadWriteCache has lock problems and slower than database if we did not use "in memory" second level cache.
Please take a consideration early release of (#2115 #2129) thank you.

Oracle Exa Data Database 500 Thread Api Call

2 db read(very little tables), 1 Cache read(Read-Write Cache), 1 insert

  1. Second level cache disabled, query cache disabled
    test01

  2. Second level cache enabled with master code
    test02

  3. Second level cache enabled with your fixes including Statefull Session commit performance issue when nothing changed and second level cache with query cache enabled #2115 Prevent calling UpdateTimesStampsCache for non cached entites #2129
    test03


2 db read(very little tables), 1 Cache read(Nonstrick Read-Write Cache), 1 insert

  1. Second level cache enabled with master code
    test04

  2. Second level cache enabled with your fixes including Statefull Session commit performance issue when nothing changed and second level cache with query cache enabled #2115 Prevent calling UpdateTimesStampsCache for non cached entites #2129
    test05

@hazzik hazzik added p: Minor and removed p: Lowest labels Apr 15, 2019
hazzik added a commit to hazzik/nhibernate-core that referenced this issue Apr 29, 2019
@maca88
Copy link
Contributor

maca88 commented May 3, 2019

ReadWriteCache has lock problems and slower than database if we did not use "in memory" second level cache.

#2147 should fix that.

@gokhanabatay
Copy link
Contributor Author

@hazzik , @maca88 hi issue still exists when do you plan to merge and make a release.

@gokhanabatay
Copy link
Contributor Author

gokhanabatay commented Jun 2, 2021

#2744 #2742 merge of pull request, there will be no need custom UpdateTimestampsCache.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants