[JBoss JIRA] Created: (JBCACHE-1016) Changes in Serializable objects are never replicated
by Jacek Halat (JIRA)
Changes in Serializable objects are never replicated
----------------------------------------------------
Key: JBCACHE-1016
URL: http://jira.jboss.com/jira/browse/JBCACHE-1016
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: PojoCache
Affects Versions: 1.4.1.SP3
Environment: Windows XP, jdk1.5.0_06
Reporter: Jacek Halat
Assigned To: Jason T. Greene
Assume that we have Serializable object stored in PojoCache. (using putObject() method)
If you get object from cache (using getObject() method), modify any field (non-transient) in object and store again object under this same node, changes made in obejct would be never replicated to another cache instances in cluster.
Probably in method TreeCacheAopDelegate._putObject() has incorrect condition:
if(oldValue == obj) return obj; // value already in cache. return right away.
If obj was loaded from cache, this condition is always true and changes made in object would never be replicated.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 7 months
[JBoss JIRA] Created: (JBCACHE-835) PojoCache need merge api?
by Ben Wang (JIRA)
PojoCache need merge api?
-------------------------
Key: JBCACHE-835
URL: http://jira.jboss.com/jira/browse/JBCACHE-835
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: PojoCache
Reporter: Ben Wang
Assigned To: Ben Wang
Fix For: PojoCache
Currently, PojoCache attach api will override the current pojo in the cache. It doesn't really have a merge functionality. Question is do we really need to have a merge api?
The following is the spec for the ejb3 entity manager merge api. However, the ejb3 em api doesn't quite apply in the case of PojoCache. You can see the object identity is by PK instead of reference. So during merge, a copy of Pojo is created instead.
The TravelAgentBean.updateCabin() method takes its cabin parameter and merges it back into the current persistence context of the entity manager by calling the merge() operation:
@PersistenceContext EntityManager entityManager;
@TransactionAttribute(REQUIRED)
public void updateCabin(Cabin cabin) {
Cabin copy = entityManager.merge(cabin);
}
The changes made by the remote Swing client will now be reflected in persistence storage when the entity manager decides to flush to the database. The following rules apply when merging in the cabin parameter of the updateCabin() method:
• If the entity manager isn't already managing a Cabin instance with the same ID, a full copy of the parameter is made and returned from the merge() method. This copy is managed by the entity manager, and any additional setter methods called on this copy will be synchronized with the database when the EntityManager decides to flush. The cabin parameter remains detached and unmanaged.
• If the entity manager is already managing a Cabin instance with the same primary key, then the contents of the parameter are copied into this managed object instance. The merge() operation will return this managed instance. The cabin parameter remains detached and unmanaged.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 7 months
[JBoss JIRA] Created: (JBCACHE-712) PojoCache needs a new tutorial gui
by Ben Wang (JIRA)
PojoCache needs a new tutorial gui
----------------------------------
Key: JBCACHE-712
URL: http://jira.jboss.com/jira/browse/JBCACHE-712
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: PojoCache
Reporter: Ben Wang
Assigned To: Ben Wang
Fix For: 2.0.0
Currently, the gui for PojoCache just display the internal cache node straight out so user can observe the field-level change. This however may not work under 2.0 since the internal ojbect model has changed.
One possiblity is the user will have to inspect the internal area as well (that is clouded by a random GUID though). The other one is we add intelligence to the GUI such that display is for object view.
This can relate to the CacheIDE as well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 7 months
[JBoss JIRA] Created: (JBCACHE-697) PojoCache Collection sub-field when detached will revert back to the original reference
by Ben Wang (JIRA)
PojoCache Collection sub-field when detached will revert back to the original reference
---------------------------------------------------------------------------------------
Key: JBCACHE-697
URL: http://jira.jboss.com/jira/browse/JBCACHE-697
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: PojoCache
Reporter: Ben Wang
Assigned To: Ben Wang
Fix For: POJOCache
In PojoCache 1.4, when a Pojo has a Collection sub-object, it will dynamically replace the reference with a corresponding ClassProxy one such that we can intercept the Collection APIs. This is in attached state. When the POJO is detached, we would simply keep the ClassProxy reference but rather point the interceptor to the original reference. This works fine except when the POJO is meant for remoting as ClassProxy is not Serializable and not for direct manipulation.
The solution is when a POJO is detached, it will dynamically swap back the original reference and discard the ClassProxy. This way, it is semantically similar to a regular POJO as well. There will be no issue of Remoting, as an example.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 7 months