We are having a requirement in which we want to update the state of a JPA object in coherence cache with out having to update it in database.
We are currently using query.setHint( QueryHints.QUERY_REDIRECTOR, new IgnoreDefaultRedirector() ); to impliment caching .
Any Example to achieve this is Appreciated.
It sounds like you are using TopLink Grid (http://www.oracle.com/technetwork/middleware/ias/tl-grid-097210.html).
In that scenario TopLink Grid controls the usage of Coherence caches, including how many separate caches are used (it uses a separate cache per entity type; the cache names by default are the unqualified names of the entity classes). The keys of the Coherence caches are the IDs of the entities, and the values are the actual entity objects (possibly wrapped, see below), not "CacheEntry" objects from which entities are constructed, as is the case with Hibernate second-level caching.
The only way I know to update the state of a JPA entity cached in Coherence by TopLink Grid is to violate the encapsulation of TopLink Grid - i.e. bypass the JPA API, and use the Coherence API directly, with knowledge of how TopLink Grid uses Coherence caches. For example you could use a ConditionalPut processor (with the condition being AlwaysFilter.INSTANCE), or perhaps a PofUpdater processor, to update your entity.
But be aware that there are some complexities to do with relationships between entities. If an entity has relationship mappings, the value in the Coherence cache for that entity is an instance of a generated class wrapping the actual entity and holding relationship information. So you'll have to account for that when using the Coherence API directly on a TopLink Grid cache (see http://docs.oracle.com/middleware/1212/coherence/COHIG/tlg_integrate.htm#BGBCDFFJ).
Related
Given your example:
https://github.com/corda/flow-db
I have a question.
Is it ok to create and store custom data within the Node database? Reading the Corda API Persistence section, I thought it could be used only to access the node database, and not to create new tables, etc. What would be a reasonable description of what can and what cannot be stored via CordaService?
It's totally OK to use Custom tables in Node. The ServiceHub actually provides you will a Connection Object. getServiceHub().jdbcSession(). As long as, you don't do some Update/Delete to the Nodes existing table you are fine. You can create any table you want and use it as per your need. As of now, corda doesn't expose JPA to map your tables to an Entity class. I guess you could see this feature in some future release.
I have a legacy database from which I have to extract some data and provide it as xml. For that I chose Symfony2 but now I am stuck. I would like to create one entity object, but the problem is, the data for it is distributed in two databases´(on the same server). I don't want to rewrite what I already made, so the easiest way would be to load the other database connections EntityManager in the existing repository. This is where I'am stuck. How can I load an EntityManager in a repository that uses the other connection? And what is the easiest way to "fill-in" the rest of the data of the entity? (By the way, I've used native queries in the repositories, because the legacy database is really complex and does not obey to any rules of DB design). I would be appreciate any help.
You could manage a second database connection called 'legacy', linking to the same database
than you need to map the entities to your managed connections than you could access your legacy table => entity and do whatever you want to with it ;)
http://symfony.com/doc/current/cookbook/doctrine/multiple_entity_managers.html
Does creating DbContext per query in Asp.net make EF only read the data from its cache, or does it query DB for the whole sets every time? I know about metadata caching per AppDomain, but what about just the data?
Context: data acquisition and visualisation application with MVC4 + Web API frontend, wouldn't call that "high volume", but lots of queries return the same sets of data in some shorter time frame.
Entity Framework doesn't have a data cache per AppDomain, only a cache per context instance.
If you create a new context per request or query you start with an empty cache and EF will fetch the data from the database.
Moreover, the term "cache per context instance" can be misleading as it doesn't mean that EF won't run queries to the database if the entities are already loaded in the context cache. The way how this cache works and how you can leverage it (or not) is the following:
Every LINQ-to-Entities query on a DbSet<T> or generally on an IQueryable<T> will run a database query, no matter if the entities already exist in the context or not. But if an entity with the same key as a queried entity already exists in the context EF will throw the result of that query away and return the cached entity instance back to the caller.
It does this check if the entity with the same key exists after it has run the query. (For complex queries - for example queries that contain an Include - it can't do this check before because it cannot know which entities and key values will be returned.)
That's the default behaviour (MergeOption is AppendOnly). You can change this behaviour to OverwriteChanges and other options, I believe, but none of them will avoid that LINQ queries always issue database queries.
For querying an entity just by its key you can use GetObjectByKey or Find (with DbContext) which will check first if the entity with that key is already cached in the context and then return this cached object. If not it will run a database query to load it.
You can query EF's ChangeTracker, it's especially well supported with DbContext where you have access to the context cache via the DbSet<T>.Local collection.
The problem here is that there is no logic to query the database automatically if a query on Local does not return a result. You have to write this logic manually. The even bigger problem is that a query on Local is LINQ-to-Objects and not LINQ-to-Entities (Local doesn't implement IQueryable<T>, only IEnumerable<T>), so you often have to rewrite your queries to act on Local - for example you can't use Include here, your can't use any EntityFunctions, you will get different behaviour for string comparisons regarding case sensitivity, etc., etc.
In reading an article on N-Tiered Applications, I came across information regarding concurrency tokens and change tracking information:
Another important concept to understand is that while the
default-generated entities support serialization, their
change-tracking information is stored in the ObjectStateManager (a
part of the ObjectContext), which does not support serialization.
My question is three-fold:
Is there the same thing when using DbContext?
If the only interaction with the database is in a Repository class within a using statement, does closing the database connection when the program leaves the using statement get rid of any option for change tracking?
Can this be leveraged as/with a Concurrency Token?
Yes. DbContext is just wrapper around ObjectContext and it exposes change tracking information through ChangeTracker property (returns DbChangeTracker) and for particular entity through calling Entry method (returns DbEntityEntry<T>).
Yes. Closing context will remove all change tracking information.
Concurrency token and change tracking are two completely different concepts. Change tracking tells context what operations it has to execute on database when you call SaveChanges. It tracks changes you did on your entities since you loaded them into current context instance. Concurrency token resolves optimistic concurrency in the database => it validates that another process / thread / user / context instance didn't change the same record your context is going to modify during SaveChanges.
I've read through this article trying to understand why you want a session bean in between the client and entity bean. Is it because by letting the client access entity bean directly you would let the client know exactly all about the database?
So by having middleman (the session bean) you would only let the client know part of the database by implementing the business logic in some certain way. So only part of the database which is relevant to the client is only visible. Possibly also increase the security.
Is the above statement true?
Avoiding tight coupling between the client & the business objects, increasing manageability.
Reducing fine-grained method invocations, leads to minimize method invocation calls over the network, providing coarse-grained access to clients.
Can have centralized security & transaction constraints.
Greater flexibility & ability to cope with changes.
Exposing only required & providing simpler interface to the clients, hiding the underlying complexity and inner details, interdependencies between business components.
The article you cite is COMPLETELY out of date. Check the date, it's from 2002.
There is no such thing anymore as an entity bean in EJB (they are currently retained for backwards compatibility, but are on the verge of being purged completely). Entity beans where awkward things; a model object (e.g. Person) that lives completely in the container and where access to every property of it (e.g. getName, getAge) required a remote container call.
In this time and age, we have JPA entities that are POJOs and contain only data. Don't confuse a JPA entity with this ancient EJB entity bean. They sound similar but are completely different things. JPA entities can be safely send to a (remote) client. If you are really concerned that the names used in your entity reveal your DB structure, you could use XML mapping files instead of annotations and use completely different names.
That said, session beans can still perfectly be used to implement the Facade pattern if that's needed. This pattern is indeed used to give clients a simplified and often restricted view of your system. It's just that the idea of using session beans as a Facade for entity beans is completely outdated.
It is to simplify the work of the client. The Facade presents a simple interface and hides the complexity of the model from the client. It also makes it possible for the model to change without affecting the client, as long as the facade does not change its interface.
It decouples application logic with the business logic.
So the actual data structures and implementation can change without breaking existing code utilizing the APIs.
Of course it hides the data structure from "unknown" applications if you expose your beans to external networks