 3 | SELECT count(e) FROM Meta e, ImageNet i, Page p
WHERE e.idImage=i.id AND e.idPage=p.id; So simple ... recommended when using JPA. It seems that a Meta instance holds the IDS of an Image and a Page instances ... ) FROM Meta e, ImageNet i, Page p
WHERE e.image=i AND e.page=p Anyway, this still doesn't justify |
3 | ] cl.intelidata.jpaodb.Movil
- Unexpected object count: 142351618 (actual 142351616)
Page Relation Errors
--------------------
[1] Page #36099460 unexpected exception: null
[2] Page #36099460 last key is null, parent page #43650945 next key is ('3.203.10.00.100000','95798112',2421822
8)
[3 |
3 | .ObjectProperty - Unexpected object count: 49830620 (actual 49830619) Page Content Errors ------------------- [1] Page #16748245 has a non first section entry (at entry 1). Index Errors ------------ [1 ... : Page#7880349 5:194359909 0/2 0+1954/2699 ... The main error message may possibly reflect |
3 | caching 1 MB (4 256KB sized pages). The goal is to have frequent PersistenceManager L1 cache hit ... mentioned above) appropriate to achieve this goal? Having larger database pages may have other effects (e.g. searching for an object in a larger page could take longer). So, as with most tuning questions |
3 | in memory was quite a challenge even with 3GB heap space. So I did paging using two loops.
for (int page=0; page < resultCount; page+=pageSize) {
Query q = em.createQuery("query");
for (Tuple t : q.setFirstResult(page).setMaxResults(pageSize).getResultList()) {
// work |
3 | splits large objects (> 2000 bytes) into pages. Somehow the stack trace indicates an unexpected state in which the same object is marked as small in one page and as large in another page. Maybe ... : 3691044274576634723 (expected 1378) [5] Unexpected total page count: 8719319783396618851 (expected 2816 |
2 | on the server side became higher mainly due to increasing page cache size. I see that the test uses 4 different databases (2 large and 2 small). The default size of each page cache (per database) is 64MB ... (page caches of the 2 other databases, query results caches, etc.) consume additional memory |
2 | done inside the DB if possible. ObjectDB manages several cache data structures: Page cache Query ... these settings: Page Cache Query Cache: Page |
2 | more robust and target the issue directly if possible. It was a bug in the page cache. This cache can hold several different versions of the same database page (representing pages that were modified by different transactions) and it should serve the right version of every page for every user (depending |
2 | further information. The stack trace is related to dilution of pages from the page cache ... relevant stack traces may indicate an infinite loop in purging pages from the cache, i.e. #1 and #3 ... .service.ServiceRunner.run(Unknown Source) I suspect that somehow a list of cached pages contains |
