March 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Commented: (JBAS-1098) Foreign key violation during cascade delete

by Gunnar Grim (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1098?page=comments#action_12355968 ] Gunnar Grim commented on JBAS-1098: ----------------------------------- The batch-cascade-delete workaround can't be used when there are more than one level of cascade delete. Why is this issue rejected? > Foreign key violation during cascade delete > ------------------------------------------- > > Key: JBAS-1098 > URL: http://jira.jboss.com/jira/browse/JBAS-1098 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CMP service > Affects Versions: JBossAS-3.2.6 Final > Reporter: SourceForge User > Assigned To: Alexey Loubyansky > Fix For: No Release > > > SourceForge Submitter: sflexus . > JBoss 3.2.5, JDK 1.4.2_04, Linux. > I have CMP Entity Customer and CMP entity Album with > the following relationships: > 1) 1 Customer has Many Albums > 2) 1 Customer has 1 Album "Inbox" > 3) 1 Customer has 1 Album "Private" > 4) 1 Customer has 1 Album "Recycle Bin" > So basically there are 3 Albums each of which has double > relationship to Customer, both 1-1 and 1-M > Relationship (1) has cascade-delete on Album side, so if > customer is deleted, all his albums should be deleted. > Relationships (2)-(4) has NO cascade-delete setting, > since (1) should be enough, as it references ALL > customer's albums, including those referenced in (2)-(4). > There are other entities related to Customer in the > application, but they seem non-important (at first sight). > If I try to remove Customer instance, I get foreigh key > violation in the database. All foreign keys were created > by JBoss itself. I have attached TRACE-level log. What > happens is that all 3 albums (inbox, private and recycle > bin, their IDs are 162, 163 and 164) are scheduled for > cascade delete, but only the one with ID=164 is updated > to set its CMR column to NULL before issuing DELETE > FROM Customer SQL. The foreign key fk_album_owner > which is being violated corresponds to relation (1) "1 > Customer has Many Albums". > The interesting thing is that if I redeploy the application > and issue remove again, it completes normally! Looks like > it depends on some cache state. > Two files are attached. First one demonstrates foreign > key violation, second one demonstrates success deletion > after application is redeployed. -- 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

19 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1005) Genericise public intergaces

by Manik Surtani (JIRA)

Genericise public intergaces ---------------------------- Key: JBCACHE-1005 URL: http://jira.jboss.com/jira/browse/JBCACHE-1005 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Manik Surtani Assigned To: Manik Surtani -- 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

19 years, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-950) Expose information about buddy group membership

by Brian Stansberry (JIRA)

Expose information about buddy group membership ----------------------------------------------- Key: JBCACHE-950 URL: http://jira.jboss.com/jira/browse/JBCACHE-950 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Manik Surtani Currently there is no way for external code to find out any information about how the cache participates in buddy relationships. Two issues (probably should be subtasks): 1) BuddyManager exposes getBuddyAddresses() but that only provides info about the group for which the node is data owner, not for any groups the node participates in as a buddy. Also, it returns an internal data structure, making it unsafe to expose to random code. Because of this, if a "primary buddy" wanted to gravitate some or all data upon exit of the data owner, it would have no way to know if it is primary. Having all buddies gravitate data would be "a bad thing". 1) In 2.0.0 I believe the BuddyManager is not available except through CacheSPI. Perhaps some info about buddy group membership could be exposed via RuntimeConfig. -- 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

19 years, 1 month

2
3
0 / 0

[JBoss JIRA] Created: (JBAOP-370) Upgrade qdox to 1.6

by Kabir Khan (JIRA)

Upgrade qdox to 1.6 ------------------- Key: JBAOP-370 URL: http://jira.jboss.com/jira/browse/JBAOP-370 Project: JBoss AOP Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.alpha3, 1.5.4.SP2 Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: 2.0.0.alpha4, 2.0.0.alpha3 -- 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

19 years, 1 month

1
5
0 / 0

[JBoss JIRA] Created: (JBAS-3515) Enable Streaming State Transfer for Cluster partition state

by Brian Stansberry (JIRA)

Enable Streaming State Transfer for Cluster partition state ----------------------------------------------------------- Key: JBAS-3515 URL: http://jira.jboss.com/jira/browse/JBAS-3515 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.Beta The only remaining non-JBossCache state transfer in AS 5 is for HASessionState (EJB 2x SFSBs.) But, to be complete we want to add it as an option, and use it by default. -- 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

19 years, 1 month

4
7
0 / 0

[JBoss JIRA] Updated: (JGRP-176) Asynchronous dispatching of requests in RequestCorrelator

by Bela Ban (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-176?page=all ] Bela Ban updated JGRP-176: -------------------------- Fix Version/s: 2.6 (was: 2.5) Moved to 2.6, as break-the-locks (JBCACHE-326) has been moved to JBossCache 2.1.0. Note: we may not even need this functionality anymore, as the concurrent stack might already solve this by delivering messages from different senders on different threads > Asynchronous dispatching of requests in RequestCorrelator > --------------------------------------------------------- > > Key: JGRP-176 > URL: http://jira.jboss.com/jira/browse/JGRP-176 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 2.2.9.1, 2.2.9, 2.2.8 > Reporter: Bela Ban > Assigned To: Vladimir Blagojevic > Fix For: 2.6 > > > In RequestCorrelator.handleRequest(), we call handle(Message) on the registered RequestHandler (RpcDispatcher in the case of JBossCache). > Because of http://jira.jboss.com/jira/browse/JBCACHE-326, we need to provide an asynchronous way of calling handle(Message), which doesn't need to wait for the call to return, but is notified later when the response is ready (or not at all if the call is asynchronous). > This could be implemented using a subinterface of RequestHandler (e.g. AsyncRequestHandler), and a *future*. -- 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

19 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-4201) Need a patch for http://jira.jboss.com/jira/browse/JBAS-1690 for 4.0.2 - Timer.cancel in a transaction never calls TimerImpl.killTimer

by Jay Howell (JIRA)

Need a patch for http://jira.jboss.com/jira/browse/JBAS-1690 for 4.0.2 - Timer.cancel in a transaction never calls TimerImpl.killTimer -------------------------------------------------------------------------------------------------------------------------------------- Key: JBAS-4201 URL: http://jira.jboss.com/jira/browse/JBAS-4201 Project: JBoss Application Server Issue Type: Patch Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.0.2 Final Reporter: Jay Howell A customer is requesting a patch for the bug http://jira.jboss.com/jira/browse/JBAS-1690 for 4.0.2 - Timer.cancel in a transaction never calls TimerImpl.killTimer for 4.0.2. This is fixed in 4.0.4, but they have not had time to test and certify 4.0.4. This is a production outage. -- 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

19 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-418) MuxChannel.getState() always returns false with StreamingStateTransfer protocol

by Jerry Gauthier (JIRA)

MuxChannel.getState() always returns false with StreamingStateTransfer protocol ------------------------------------------------------------------------------- Key: JGRP-418 URL: http://jira.jboss.com/jira/browse/JGRP-418 Project: JGroups Issue Type: Bug Affects Versions: 2.4.1 Reporter: Jerry Gauthier Assigned To: Vladimir Blagojevic When I execute DRMTestCase.testIsMasterReplica() in JBossAS 5.0 using the StreamingStateTransfer protocol, MuxChannel.getState() always returns false. This method is invoked from ClusterPartition.fetchState(); it returns false even though debugging the other node in a two node cluster shows that the state has been retrieved. If I use the StateTransfer protocol instead, the transfer is successful. I started debugging this issue and determined that ClusterPartition never successfully retrieves state from the multiplexer channel when using StreamingStateTransfer. It's possible that the problem lies in ClusterPartition but this can't be determined until it's understood why getState() is returning false. This problem can be replicated as follows. 1) Ensure that you're using the latest JBossAS 5.0.0 HEAD cluster and testsuite\cluster code as I made recent changes in this area. 2) Modify ..\cluster\output\resources\jgroups-multiplexer.sar\META-INF\multiplexer-stacks.xml. Change the "tunnel" stack to use StreamingStateTransfer instead of StateTransfer. This is the stack used by the test in DRMTestCase.testIsMasterReplica(). 3) Running the test should show the following result. <error message="Initial serviceState transfer failed: Channel.getState() returned false" type="java.lang.IllegalStateException">java.lang.IllegalStateException: Initial serviceState transfer failed: Channel.getState() returned false at org.jboss.ha.framework.server.ClusterPartition.fetchState(ClusterPartition.java:511) at org.jboss.ha.framework.server.ClusterPartition.startService(ClusterPartition.java:335) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196) at org.jboss.test.cluster.test.DRMTestCase.testIsMasterReplica(DRMTestCase.java:686) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) </error> 4) Note: DRMTestCase.testIsMasterReplica() won't execute successfully with the StateTransfer protocol until JGRP-416 is resolved. This issue causes JGroups to issue UnsupportedOperationException for UnmodifiableVector during the merge process in the test case. I've patched the problem in JGroups locally and confirmed that the test does run successfully for StateTransfer after this issue is resolved. It's not necessary to patch JGRP-416 to investigate MuxChannel.getState() as the state problem occurs before the UnmodifiableVector problem. -- 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

19 years, 1 month

2
1
0 / 0

[JBoss JIRA] Commented: (JBPORTAL-692) Calendar Portlet

by Peter Oates (JIRA)

[ http://jira.jboss.com/jira/browse/JBPORTAL-692?page=comments#action_12355945 ] Peter Oates commented on JBPORTAL-692: -------------------------------------- Hi, I'm having a issue deploying this portlet. I build the portlet with ant,then i put both har and war files in the deploy dir. I'm testing it with the standard jboss portal bundle downloaded.Im getting many errors but the culmination is this. --- MBeans waiting for other MBeans --- ObjectName: portal:service=CalendarioHibernate State: CONFIGURED I Depend On: jboss.jca:service=DataSourceBinding,name=jdbc/intranetDS --- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM --- ObjectName: jboss.jca:service=DataSourceBinding,name=jdbc/intranetDS State: NOTYETINSTALLED Depends On Me: portal:service=CalendarioHibernate > Calendar Portlet > ---------------- > > Key: JBPORTAL-692 > URL: http://jira.jboss.com/jira/browse/JBPORTAL-692 > Project: JBoss Portal > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Portal Samples > Reporter: Roy Russo > Priority: Optional > Attachments: CalendarioPortlet.zip, CalendarioPortlet.zip, CalendarioPortlet.zip, MyFacesPortletExtension.zip > > > Simple Calendar portlet that displays a calendar of the month, allowing for month-to-month navigation. > - User should be able to access a specific day and add an event to it. > - Days with events, should be highlighted in the month-view. Should not be tied to external calendar services, such as MS Exchange. > *A calendar sharing feature is a nice-to-have addon. -- 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

19 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-432) DistributedHashtable: clear() hangs

by Bela Ban (JIRA)

DistributedHashtable: clear() hangs ----------------------------------- Key: JGRP-432 URL: http://jira.jboss.com/jira/browse/JGRP-432 Project: JGroups Issue Type: Bug Affects Versions: 2.4.1 SP1 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 See DistributedHashtableUnitTest -- 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

19 years, 1 month

1
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2007